Avoid exceptions on fetching uninitialized names in ClassLikes

[ohader]

Similar to the behavior of ClassLikes::classImplements() (#5984),
the following methods will return a false/empty value in case a
specific class name has not been initialized yet:

• ClassLikes::classExtends() returns false
• ClassLikes::getParentInterfaces() returns []

---

Fixes: #7520
Fixes: #10350
Fixes: #10152

[ohader]

Previous comment from master PR are still valid (#10724 (comment))

I wonder if rescanning whole files is really necessary. My idea was to walk classlikes / functionlikes after the codebase population and tighten the intersections. E.g. if the return method was left as MySessionHandler&SessionHandlerInterface where MySessionHandler implements SessionHandlerInterface (because either MySessionHandler or SessionHandlerInterface were unavailable during the initial scan) it would be tightened to MySessionHandler.

I had something similar in my mind as well, but did not find a good way to "communicate" from the specific inner parts to the outer parts that would trigger those optimizations after codebase population. Basically like:

• hold unresolved/failed statements/names in memory (probably required for anonymous classes)
• process different strategies to resolve the types (e.g. simplifying the types like ArrayObject&Countable → ArrayObject; if that fails, reprocess the parser statements; if that fails reprocess the whole file) - this might be an additional setting in psalm.xml config file
• in case not all previously unresolved statements/names could be resolved, the process could either fail with an exception or continue with a generic type, e.g. TMixed - this might be another config option in psalm.xml

[simonberger]

I did test it. While my crash pre-scanning the project files does not happen anymore, I got a crash while scanning the project files.

Uncaught Exception: Psalm\Exception\UnpreparedAnalysisException File /var/www/project/src/SomeMockFile.php has not been properly scanned

Emitted in /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Analyzer/FileAnalyzer.php:124
Stack trace in the forked worker:
#0 /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Codebase/Analyzer.php(1591): Psalm\Internal\Analyzer\FileAnalyzer->analyze()
#1 /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Fork/Pool.php(191): Psalm\Internal\Codebase\Analyzer->analysisWorker()
#2 /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Codebase/Analyzer.php(372): Psalm\Internal\Fork\Pool->__construct()
#3 /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Codebase/Analyzer.php(272): Psalm\Internal\Codebase\Analyzer->doAnalysis()
#4 /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Analyzer/ProjectAnalyzer.php(552): Psalm\Internal\Codebase\Analyzer->analyzeFiles()

[ohader]

I did test it. While my crash pre-scanning the project files does not happen anymore, I got a crash while scanning the project files.

Uncaught Exception: Psalm\Exception\UnpreparedAnalysisException File /var/www/project/src/SomeMockFile.php has not been properly scanned

Emitted in /var/www/project/vendor/vimeo/psalm/src/Psalm/Internal/Analyzer/FileAnalyzer.php:124

It seems this is a new/different issue now. Can you try running Psalm single-threaded (./psalm --threads=1 ...)?
Just to make sure it's not the issue I referenced in the TODO section of this PR description. Thx!

[simonberger]

It does not fail without threads (more details in the mentioned issue), but as far as I know the whole issue is at least mostly related to using multithreading.
Very few of the people affected, tested it with --threads=1 or --debug.

[ohader]

While working on additional tests for unknown/undefined interfaces used in intersections, I realized that the behavior is different. Thus the \Stringable&\JsonSerializable example failed since both the classes actually existed - when those classes are not existing, the process continues and silently ignores that lack of information.

Thus, it seems there might be a much simpler solution than reprocessing, which is more in line with the rest of the assumptions in PsalmPHP:

• add some more $classlike_storage_provider->has($interface) checks and we're basically good to go
• there are already plenty of these try .. catch blocks and ->has(..) checks in \Psalm\Internal\Codebase\ClassLikes(https://github.com/vimeo/psalm/blob/5.x/src/Psalm/Internal/Codebase/ClassLikes.php) already
• I dumped the previous draft-code to a separate branch at https://github.com/ohader/psalm/tree/10350-intersections-outdated-5.x in case it gets relevant again

I've updated the PR accordingly...

[ohader]

Test cases explicitly expect an exception to infer further type checks... which feels super weird:

psalm/tests/Internal/Codebase/InternalCallMapHandlerTest.php

Lines 649 to 659 in 1c36da6

	try {
	$this->assertTrue(UnionTypeComparator::isContainedBy(self::$codebase, $callMapType, $expectedType, false, false, null, false, false), "{$msgPrefix} type '{$specified}' is not contained by reflected type '{$reflected}'");
	} catch (InvalidArgumentException $e) {
	if (preg_match('/^Could not get class storage for (.*)$/', $e->getMessage(), $matches)
	&& !class_exists($matches[1])
	&& !interface_exists($matches[1])
	&& !enum_exists($matches[1])
	) {
	$this->fail("Class used in CallMap does not exist: {$matches[1]}");
	}
	}

ClassLikes::classExtends() now returns false instead of throwing an exception by implicitly invoking $this->classlike_storage_provider->get and waiting for that InvalidArgumentException.

[ohader]

I'll surrender now... still static keyword failures in the CallMap unit tests... but only for PHP 8.2 and 8.3. I'm not able to reproduce that locally with PHP 8.2.

[ohader]

→ Phew... I'm dropping this change in favor of the original PR at #10720