NodeScopeResolver: Prevent repetitive union of static types

[staabm]

re-use types introduced in #4841

removes a few TypeCombinator::union calls

---

since TypeCombinator::union is the slowest path we have right now, this is a great thing to have.

[phpstan-bot]

This pull request has been marked as ready for review.

[VincentLanglet]

I think name could be challenged for 3 reasons:

• Existing methods are called falsey (and truthy) and not getFalseyType.
  Should it be something like nonIntArrayKeyValue ?

• I had trouble ton understand what was IntArrayKeyValueType and nonIntArrayKeyValueType. Should another name be use ? With offset maybe ?

• nonInt is not really valid since we was using $offsetType->isInteger()->yes() for getIntArrayKeyValueType and getNonIntArrayKeyValueType in the other case, including the MAYBE case. So it's more a general case.

Maybe something like

generalOffsetAccessible()
intOffsetAccessible()

[staabm]

great suggestions. I was not happy with the names either.

I now have a mix of your suggestions and my own idea.

wdyt?

[VincentLanglet]

You'll have to rename the variable inside the method too.

It's just unclear why you're calling this OffsetValueType.

If I have $foo[$bar] = $baz,

• bar is the key/index/offset/dim type
• baz is the value type

You seems to call $foo the offsetValue. Is it something often used in PHPStan codebase ?
I assume it's related to HasOffsetValueType but here we are doing nothing with the Value, so it's more HasOffsetType no ? Like hasIntOffset.

[staabm]

the method is returning the Type for $baz (speaking from your example) - thats why I call it OffsetValueType

[VincentLanglet]

Oh, I thought it was returning the type for $foo.
With the idea that $string[$int] is allowed but not $string[$string].

I'm surprise by the fact it returns $baz cause then, it shouldn't forbid scalar... (?)

[staabm]

ohh you are right. its $foo not $baz and thats the wrong term as you already pointed out

[ondrejmirtes]

Nice, thank you!