Issue when inferring the key of an iterable

[gnutix]

Bug report

In #7031, I reported two issues when trying to infer the key of an iterable, but forgot to create a separate issue as was asked. Here it is.

Code snippet that reproduces the problem

https://phpstan.org/r/efdae2f5-0033-4a4f-8c6d-66c31136829f
https://phpstan.org/r/884d3d97-9b8d-4924-8559-5b8c7449ef31

Expected output

The type should be properly inferred both for the simple string and the complex (class constant) one.

Did PHPStan help you today? Did it make you happy in any way?

Just upgraded to the latest version and had yet one less issue reported in my project's baseline. <3 Thank you for all your hard work!

[phpstan-bot]

@gnutix After the latest push in 1.11.x, PHPStan now reports different result with your code snippet:

@@ @@
+64: Parameter #2 $fn of function collectWithKeys expects callable(array{maximumTimeRange: string, duration: string, matchedSchedulesIds: array}, int|string): iterable<int|string, mixed>, Closure(array): Generator<mixed, mixed, mixed, void> given.
 64: Unable to resolve the template type L in call to function collectWithKeys
 65: Dumped type: string

Full report

Line	Error
64	`Parameter #2 $fn of function collectWithKeys expects callable(array{maximumTimeRange: string, duration: string, matchedSchedulesIds: array}, int
64	Unable to resolve the template type L in call to function collectWithKeys
65	Dumped type: string

[phpstan-bot]

@gnutix After the latest push in 1.11.x, PHPStan now reports different result with your code snippet:

@@ @@
+PHP 8.0 – 8.1 (2 errors)
+==========
+
+64: Unable to resolve the template type L in call to function collectWithKeys
+65: Dumped type: string
+
+PHP 7.1 – 7.4 (3 errors)
+==========
+
+41: Non-capturing catch is supported only on PHP 8.0 and later.
 64: Unable to resolve the template type L in call to function collectWithKeys
 65: Dumped type: string

Full report

PHP 8.0 – 8.1 (2 errors)

Line	Error
64	Unable to resolve the template type L in call to function collectWithKeys
65	Dumped type: string

PHP 7.1 – 7.4 (3 errors)

Line	Error
41	Non-capturing catch is supported only on PHP 8.0 and later.
64	Unable to resolve the template type L in call to function collectWithKeys
65	Dumped type: string

[phpstan-bot]

@gnutix After the latest push in 1.11.x, PHPStan now reports different result with your code snippet:

@@ @@
 92: Dumped type: array<string, string>
 94: Static property CsvExport::$headers (array<'else'|'entirely'|'something', string>) does not accept array<string, string>.
 
-PHP 7.1 – 7.4 (4 errors)
+PHP 7.1 – 7.4 (5 errors)
 ==========
 
+41: Non-capturing catch is supported only on PHP 8.0 and later.
 88: Dumped type: 'else'|'entirely'|'something'
 89: Named arguments are supported only on PHP 8.0 and later.
 92: Dumped type: array<string, string>
 94: Static property CsvExport::$headers (array<'else'|'entirely'|'something', string>) does not accept array<string, string>.

Full report

PHP 8.0 – 8.1 (3 errors)

Line	Error
88	`Dumped type: 'else'
92	Dumped type: array<string, string>
94	`Static property CsvExport::$headers (array<'else'

PHP 7.1 – 7.4 (5 errors)

Line	Error
41	Non-capturing catch is supported only on PHP 8.0 and later.
88	`Dumped type: 'else'
89	Named arguments are supported only on PHP 8.0 and later.
92	Dumped type: array<string, string>
94	`Static property CsvExport::$headers (array<'else'

[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.