\Ds\Map::get() false positive with numeric-string

[enumag]

Bug report

Most likely a bug somewhere in DsMapDynamicReturnTypeExtension or possibly in ParametersAcceptorSelector but so far I was unable to figure it out.

Code snippet that reproduces the problem

https://phpstan.org/r/9c9c6dd3-0bb0-4008-90e7-25f37c3cd687

Expected output

no error

[phpstan-bot]

@enumag After the latest commit in dev-master, PHPStan now reports different result with your code snippet:

@@ @@
-9: Function mapGet() should return string&numeric but returns string.
+7: Function mapGet() should return string but return statement is missing.

Full report

Line	Error
7	Function mapGet() should return string but return statement is missing.

[phpstan-bot]

@enumag After the latest commit in dev-master, PHPStan now reports different result with your code snippet:

@@ @@
-9: Function mapGet() should return string&numeric but returns string.
+9: Function mapGet() should return numeric-string but returns string.

Full report

Line	Error
9	Function mapGet() should return numeric-string but returns string.

[ZebulanStanphill]

I recently ran into a very similar thing (probably caused by the same root issue) that happens with int versus positive-int.

https://phpstan.org/r/8718979a-6773-4bf8-b42d-b2c9dcae0d3e

Notably, in both cases the issue does not occur if Ds\Map#get is not provided a second parameter (the one used to provide a default value and prevent throwing).

[ZebulanStanphill]

Upon examining DsMapDynamicReturnTypeExtension, I think the issue is unrelated to both it and ParametersAcceptorSelector. Rather, I think it has something to do with the type union in the method stub's return type being improperly collapsed somewhere.

The problem really has nothing to do with \Ds\Map in particular; the issue can be reproduced using 2 simple functions, as demonstrated here: https://phpstan.org/r/78f6c7dc-22cf-4c02-b092-0cbd76fa32f3.

It looks like perhaps the issue actually has something to do with generics?

cc @ondrejmirtes

[rvanvelzen]

This is probably the same issue as #6653 - the type is generalized for mixed bounds. For the last example, if you were to bound TDefault as string it would work. That isn't a solution to this issue though, just shows why it happens.

[ondrejmirtes]

Last night I came up with the idea that we mostly shouldn't generalize the generic type variables, except when they're in object generics, like Foo<int>.

Here's the resulting PR: phpstan/phpstan-src#2818

We can't do this for objects, because I want new Collection([1, 2, 3]) to become Collection<int>. This could be improved in the future thanks to this suggestion: #6732 (comment) (but it's pretty complex to implement so for now it has to wait).

The new behaviour now only applies to bleeding edge (https://phpstan.org/blog/what-is-bleeding-edge) so definitely enable it to get the taste of the future 👍

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.