from my POV the problem in the reported types is

-non-empty-array<int<0, 9>, non-empty-array<0|1, string>>
+non-empty-array<int<0, 9>, non-empty-array<int<0, 9>, string>>

so thats why my idea was that in the deeper nested key-type no generalization happend and thats what missing.

IMO when only one of the involved scopes contains a general or constant array, we don't do deep generalization (recursive) in

• phpstan-src/src/Analyser/MutatingScope.php

  Line 5395 in c87456e

  $resultTypes[] = TypeCombinator::union(...$constantArrays['a']);

• phpstan-src/src/Analyser/MutatingScope.php

  Line 5436 in c87456e

  $resultTypes[] = TypeCombinator::union(...$constantArrays['b']);

• phpstan-src/src/Analyser/MutatingScope.php

  Line 5441 in c87456e

  $resultTypes[] = TypeCombinator::union(...$generalArrays['a']);

• phpstan-src/src/Analyser/MutatingScope.php

  Line 5481 in c87456e

  $resultTypes[] = TypeCombinator::union(...$generalArrays['b']);

(but I am looking at this stuff for the first time... I might be wrong :))

Yeah, it's possible the problem is with generalization and not merging scopes, I was just debugging this in my head, not in code 😂

after more debugging I have a new idea :)

it seems we update types for expressions, but do not update other types which reference these variables by offset, see e.g.

I think $locations[$i] indirectly depends on $j in its key-type of the array

Yeah, that's basically what I'm talking about in #4372 (comment), this is what I imagine the problem would look like.

After updating $i, we need to throw away $locations[$i]. After updating $locations, we need to throw away $locations[$i].

I think that actually "updating" after assignment works fine, but merging scopes probably doesn't handle this.

I finally understood what you are trying to tell me :).

This pull request has been marked as ready for review.

I'm also trying to figure out the other regression.

thank you!

I don't know yet, will think about it more :) Thank you.