This appears to be wrong - the doc is

* @param string|string[]|int|bool|null $default The default value (must be null for InputOption::VALUE_NONE)

so i'm seeing this reported for my calls to to addOption where I'm passing int

Although its true that getOption has return type of string|string[]|bool|null - which will likely also be wrong in this case... maybe the symfony docblock needs to be fixed

the better reference, https://github.com/phpstan/phpstan-symfony/pull/45/files#diff-e486177dda816bfb1e25cf9f96abb146R69

The thing is, if you pass the option from the console, you can only ever get string there (or bool in case of VALUE_NONE, or null if you don't pass the option at all). You can pass a different type as a default, but that is imho wrong (as suggested by the docblock), and there is a rule that should forbid that.

So there are two options here: 1) go with the docblock and just restrict it's allowed types based on the mode, or 2) union with the default's type, even if it's not allowed by the docblock. I went with the first approach. Do you suggest we should go with the second? I realize that the code does not forbid that, just the docblock, so it should be ok, I just don't think it's the intended behaviour. And I specifically added the Invalid(Argument|Option)DefaultValueRule for these cases.

Interestingly this was just recently changed in Symfony - symfony/symfony#29201 - seems there is a bit of inconsistency here in the docblocks and the code, the ArgvInput, normally used will only ever give you strings, but the ArrayInput, often used for testing, lets you pass int (or whatever else).

I guess given the reality is your going to get strings out for real usage, might be best to stick with what you've done. Might be also be nice to check the args to ArrayInput are also strings([]) so users dont test with different types.

You know what, I actually for some reason missed that the addOption method allows int in default. I guess I should reflect that after all.

@mcfedr done