Improve in_array assertion to extract assertions for non-literal types

[supersmile2009]

Fixes #6220

Thanks @orklah for the tip on where to check.

[supersmile2009]

The last commit fixes 2 old tests, which used to pass before because AssertionFinder::getInarrayAssertions() wasn't treating lists of literals correctly. Since list<"a"|"b"> doesn't guarantee that either of those values is actually present in the array, the assertions extracted by getInarrayAssertions() were not safe. That's what the large comment block added to AssertionFinder::getInarrayAssertions() is about.

By looking at those tests I believe that original intention was to check against a known and fixed list of constants, which is array{"a", "b"}. In fact those tests would fail even without this patch if restrict_return_types was enabled.

So I wouldn't call it a regression, it's a bug fix rather.

[orklah]

Indeed, list<"a"|"b"> doesn't guarantee the presence of one or the other, and the fact that non-empty-list<"a"|"b"> wasn't used, it didn't even guaranteed the array contained anything at all.

[orklah]

Seems awesome! Thanks :)

[supersmile2009]

1. The change to Psalm\Type::intersectUnionTypes().
   It turned out that it couldn't intersect some scalar type unions properly. (int|string)&(int|bool) returned null (like no intersection at all, not null type) and not int as expected. Now it's fixed.
2. in-array- assertion now uses slightly different syntax. Type key is simply concatenated with the prefix. The first approach that I took with separate assertion for each type couldn't work. You need to have all the types in a single context to do the intersection. Otherwise if you keep returning Empty type after separate assertion reconciliation, you get wrong errors in some cases. With the new implementation Reconcilers can intersect the types and produce correct errors, like if condition is redundant or if assertion makes no sense, because types are completely different.

[orklah]

@supersmile2009 seems like something broke in Psalm. Can you check it?

[supersmile2009]

@orklah done. Could you trigger the CI again?

[weirdan]

Thanks!

[orklah]

This triggered a new false positive in my work codebase: https://psalm.dev/r/aaa65f492c

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/aaa65f492c

<?php

class A{
 	public static array $array1 = ['a', 'b'];
 	public static array $array2 = ['c', 'd'];
}

$element = 'element2';
if(in_array($element, A::$array1, true)) {
    $_a = 1;
} elseif(in_array($element, A::$array2, true)) {
    $_a = 2;
}

Psalm output (using commit 2e7763c):

ERROR: ParadoxicalCondition - 11:10 - Condition ($element is in-array-mixed) contradicts a previously-established condition ($element is not in-array-mixed)