Inside foreach, $value is not the same as $array[$key]

[Seldaek]

Bug report

Even though I narrow down which $key is currently being looped over, $value still has an aggregate type of all possible keys, and does not update to become the stricter type associated with just that exact key. Anyway the snippet probably explains this better :D

It may be a feature request more than a bug I suppose.

Code snippet that reproduces the problem

https://phpstan.org/r/456203ce-8c04-406f-b7fb-556ac8d711ca

Expected output

No error

[phpstan-bot]

@Seldaek After the latest commit in 1.8.x, PHPStan now reports different result with your code snippet:

@@ @@
-8: Parameter #2 $array of function implode expects array<string>, array<int|string, array<string>|string> given.
+9: Offset 'classmap' does not exist on array{psr-4?: array<string, array<string>|string>, classmap?: array<int, string>}.

Full report

Line	Error
9	`Offset 'classmap' does not exist on array{psr-4?: array<string, array

[Seldaek]

@herndlm - I am not sure this is correct - I mean it's an improvement in that $value is now correct based on the $key check - but $data[$key] should IMO also be marked as existing within a foreach creating $key https://phpstan.org/r/47a8b19c-e77b-44b4-9272-b1eedf7b046b

[herndlm]

Oh, that's a bit of a weird one. Adding some internal info for @ondrejmirtes mostly and also fyi I guess :)

• phpstan cannot figure out yet that the array we're looping over must have that optional key we're using to loop over, e.g. https://phpstan.org/r/5634ffca-db70-46bb-91b4-c053ac5e41ce; this also didn't work before, I double-checked
• but, previously, before my fix, it narrowed down $data to array{psr-4?: bool, classmap?: array<int, string>}&non-empty-array'. now it is array{psr-4?: bool, classmap?: array<int, string>}
• question is why this error showed up now. the answer lies in https://github.com/phpstan/phpstan-src/blob/1.8.0/src/Rules/Arrays/NonexistentOffsetInArrayDimFetchCheck.php#L51 / TypeUtils::getOldConstantArrays which does not inspect intersection types and therefore did not consider the constant array before

this raises 3 questions for me

• should we open a new feature / issue for the foreach looping key narrow thing?
• why are intersections ignored in TypeUtils::getOldConstantArrays, shouldn't we consider them there too? I guess there's a good reason though why they are not considered there and in many other of those util methods
• is that accessory type for a constant array something that should be normalized away maybe? it feels weird at least, doesn't add more info IMO and seems to be actively confusing some checks UPDATE: it still does add value I guess though

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