why this change that stops usingT ?

Hi@stof, this change fixes several static analysis errors reported by Psalm.

The root cause is anInvalidTemplateParam error: the@template T is defined asUnitEnum|BackedEnum, but thetrue branch of the conditional return was passing this genericT toBackedEnumType, which strictly expectsclass-string<BackedEnum>.

This PR replaces the genericT with the more specificclass-string<\BackedEnum> in that branch, which satisfies the template constraint and resolves the subsequentInvalidReturnType errors.

Here is the full output from Psalm for reference:

https://github.com/symfony/symfony/actions/runs/19110924189

but this leads to a less precise type thanT.

Maybe the conditional type should use a check onT instead of$className for the analysis to work.

Hi@stof, that's a much more elegant solution. You're right, checkingT directly instead of$className should allow the static analysis to work while preserving the type precision.

I've pushed the change. Thanks 🙏🏼

Hi@stof, I tried checkingT directly in the conditional, but unfortunately, Psalm still reports the exact sameInvalidTemplateParam errors.

It seems the analyzer is unable to "narrow" the type ofT (fromUnitEnum) based on that conditional.

I've reverted to my original fix (using theclass-string<\BackedEnum>) and pushed that.

Let me know if that's okay, or if you'd prefer a different approach. Thanks!

@yoeunes are you looking at what Psalm is able to do when analyzing the code of that method, or when analyzing codecalling that method ?
The second case is more important for the value it brings to the ecosystem (and it might make sense to also check how phpstan analyzes such caller code, as projects using Symfony might use any tool).

I know that psalm is not always smart enough to analyze code of a method that combines both conditional types and generics.

Hi@stof, that's a great point, and you're right, the "caller" analysis is the most important one.

I've tested both scenarios, and this is where it gets tricky:

1. Internal Analysis (CI): Your suggestion to check(T is ...) is the most elegant, but as the CI run showed,Psalm still fails. It reports the sameInvalidTemplateParam error, as it seems unable to "narrow" the genericT (fromUnitEnum) inside the conditional.

2. Caller Analysis (User-land): To fix that Psalm error, I first tried the "less precise" workaround (BackedEnumType<class-string<\BackedEnum>, ...>). This fixes Psalm, but it then causesPHPStan to fail forcallers with anUnable to resolve the template type U error. This happens when a user calls::enum() with only one argument (ornull), as PHPStan can't inferU.

I've finally pushed a solution that makesboth analyzers happy. It's the one in the PR now, which combines the two fixes:

1. It usesBackedEnumType<class-string<\BackedEnum>, ... to satisfyPsalm's internal analysis.
2. It adds aninner conditional check for($backingType is null ? ...) to satisfyPHPStan's caller analysis (by giving it a concrete type path whenU cannot be inferred).

This final version now passes all tests, both inside Symfony's CI and when analyzing user-land code.

Here is the simple user-land script I used to reproduce and fix the PHPStan (caller) error:

<?phprequire__DIR__.'/vendor/autoload.php';useSymfony\Component\TypeInfo\TypeFactoryTrait;enum MyEnum:string {case A ='a';}class TestEnumType{use TypeFactoryTrait;}// This call (with 1 arg) triggers "Unable to resolve U"// unless the PHPDoc has the inner ($backingType is null) check.TestEnumType::enum(MyEnum::class);

Let me know if this solution looks good. Thanks!

this still looses the preciseT type for theBackedEnumType AFAICT.