Yes, looks great :)

I'll try to implement the functions as well for it to have the same functionality as the source locator.

Making the tests pass is a pain! "Works on my machine"™ 🙈

That's probably the best I can do :)

Thank you, it's nice. Do you plan to also send PRs for all the other source locators? 😊

Maybe :)

I'll add these methods to ReflectionProvider once all the sensible source locators support that:

	/**
	 * @return array<string, ClassReflection>
	 */
	public function getAllClasses(): array;

	/**
	 * @return array<string, FunctionReflection>
	 */
	public function getAllFunctions(): array;

	/**
	 * @return array<string, GlobalConstantReflection>
	 */
	public function getAllConstants(): array;

I don't want to do it sooner because it'd lead to incomplete and confusing results.

Please note that it doesn't make sense for some source locators like AutoloadSourceLocator to support this, it's fine for some to still return [].

Also I'm torn if the classes and functions should be indexed by lowercase name or not, probably yeah, so that classes like AggregateSourceLocator and ChainReflectionProvider can de-duplicate the returned results.

BTW: My implementation stems from \PHPStan\Reflection\BetterReflection\SourceLocator\OptimizedDirectorySourceLocator::locateIdentifier which does not support constants. Therefore it does not support constants as well and in that case the original behavior (empty array) remains.

And I understand how all source locators need to implement this. Otherwise it's ultra confusing :)

I actually had it previously indexed by lowercase names, but the interface specified array<int, Reflection> so I changed that. I hadn't had time to dig deeper on where and how it's actually used and if I can change it.

Yes, directory source locator doesn't look for constants, that's fine, people should follow this: https://phpstan.org/user-guide/discovering-symbols#global-constants