filter_input return type confusion when using named parameters and leaving out the filter argument

[pilif]

https://psalm.dev/r/23882663dc

all calls are equivalent, yet the last one does not yield the expected result.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/23882663dc

<?php

$a = filter_input(INPUT_POST, 'message', FILTER_DEFAULT, FILTER_FORCE_ARRAY);
assert(is_array($a));

$a = filter_input(INPUT_POST, 'message', FILTER_DEFAULT, options: FILTER_FORCE_ARRAY);
assert(is_array($a));

$a = filter_input(INPUT_POST, 'message', filter: FILTER_DEFAULT, options: FILTER_FORCE_ARRAY);
assert(is_array($a));

$a = filter_input(INPUT_POST, 'message', options: FILTER_FORCE_ARRAY);
assert(is_array($a));

Psalm output (using commit ef3b018):

ERROR: TypeDoesNotContainType - 13:8 - Type false for $a is never array<array-key, mixed>

ERROR: TypeDoesNotContainType - 13:1 - Type false for $a is never array<array-key, mixed>

[weirdan]

/cc: @kkmuffme

[kkmuffme]

Named arguments aren't supported by the params provider yet - which is the case for most return type providers in psalm too.
I think there should be a sticky issue (if that's possible in github) listing all the return/param type providers and whether psalm supports named arguments for them yet (if the function supports named arguments in the first place) or not, since those are usually good first issues since they're relatively simple to fix.

@pilif feel free to give a PR a try to add support for named arguments - if you need any help just let us know here.

[pilif]

@kkmuffme PR is attached for the filter_var and filter_input cases I wonder whether there can be a generic solution based on the available stubs though. That could work for all return type providers.

[kkmuffme]

Unfortunately, for some cases this won't be possible since PHP native functions that have variadic args have inconsistent behavior with how variadic userland functions work, so those would have to be handled separately anyway.
And for those that could - that would be great, however with how everything is extremely fragmented in psalm's code base, this would probably quite a big undertaking. This is an issue in lots of places in psalm already, that the wheel is being reinvented 30 times, bc it's unclear or undocumented that a specific functionality already exists.