Infer non-falsy-string&non-decimal-int-string for the magic name property on the UnitEnum/BackedEnum interfaces

[phpstan-bot]

Summary

Accessing the magic name property on a value typed as the \UnitEnum or \BackedEnum interface (or a @template T of \UnitEnum bound) inferred plain string. Since an enum case name is always a valid PHP label, it can never be an empty string or "0", so it should be inferred as non-falsy-string.

Changes

• src/Reflection/Php/PhpClassReflectionExtension.php: in createProperty(), when the resolved property is the magic name declared on the UnitEnum interface and no PHPDoc type was found, set its PHPDoc type to non-falsy-string (StringType intersected with AccessoryNonFalsyStringType).
• Added a regression test tests/PHPStan/Analyser/nsrt/bug-14839.php.

Root cause

BetterReflection synthesizes the magic enum members (ReflectionClass::getEnumProperties()): the name property on the UnitEnum interface is created with the native type string. PHPStan already special-cases concrete enum classes (producing a union of constant-string case names) and individual enum-case objects (EnumCaseObjectType, producing a single ConstantStringType) — both of which are non-falsy. But values typed only by the UnitEnum/BackedEnum interface (or a template bounded by them) never hit those special cases and fell back to the synthesized string.

The fix narrows the name property to non-falsy-string at the single place where the interface-declared property is reflected, which also covers BackedEnum (inherits name from UnitEnum) and @template T of \UnitEnum parameters.

Test

tests/PHPStan/Analyser/nsrt/bug-14839.php asserts:

• Foo $foo / Bar $bar (concrete enums) → 'A'|'B' (already correct, kept as a guard).
• \UnitEnum $u → non-falsy-string (was string).
• \BackedEnum $b → non-falsy-string for ->name (was string) and int|string for ->value (unchanged).
• @template T of \UnitEnum parameter → non-falsy-string (was string).

Verified the test fails before the fix (the UnitEnum/BackedEnum/template assertions reported string) and passes after.

Analogous cases probed

• Concrete enum types and individual enum-case objects (EnumCaseObjectType) — already non-falsy, no change needed.
• The backed-enum value property — intentionally left as int|string, since a backing value may legitimately be an empty string or "0".

Fixes phpstan/phpstan#14839

[staabm]

this could even include non-decimal-int-string

[phpstan-bot]

Done. I addressed staabm's review suggestion that the magic enum name property "could even include non-decimal-int-string".

What I changed

src/Reflection/Php/PhpClassReflectionExtension.php — The UnitEnum/BackedEnum interface name property now intersects three accessory constraints instead of two:

$phpDocType = TypeCombinator::intersect(
    new StringType(),
    new AccessoryNonFalsyStringType(),
    new AccessoryDecimalIntegerStringType(true),  // non-decimal-int-string
);

This is correct because an enum case name is a valid PHP label — it must start with a letter or underscore, so it can never be a decimal integer string ("0", "123", "-1", …). AccessoryDecimalIntegerStringType(true) is the existing inverse flag that represents non-decimal-int-string.

tests/PHPStan/Analyser/nsrt/bug-14839.php — Updated the three interface/template assertions from non-falsy-string to non-decimal-int-string&non-falsy-string (the order PHPStan's describe() produces).

Verification

• bug-14839 test passes; all 15 enum nsrt tests and the full NodeScopeResolverTest (1656 tests) pass.
• make phpstan → no errors.

Committed as ada64bf43 and pushed to the PR branch.