Check class constant access through constant class-name strings and class-string unions

[gnutix]

Follow-up to #5976 (same root-cause family). ClassConstantRule had a legacy string bail-out that predates Type::isClassString() / Type::getClassStringObjectType(): for a $classString::CONST fetch where the class expression is a constant class-name string, a class-string<T>, or a union thereof, the rule silently returned once $classType->isString()->yes(), so a missing constant on one or all members went unreported.

Fix

Mirrors the TypeExpr routing from #5976, adapted to class constants. Before calling RuleLevelHelper::findTypeToCheck(), a class-string-typed class expression is converted via getClassStringObjectType() and wrapped in new TypeExpr($objectType) when the object type names at least one class that is not a trait. There is no separate isClassString()->yes() guard: for any type that is not entirely a class-string (objects, unions with non-class-string members, plain string), getClassStringObjectType() yields no class name, so the conversion is skipped by the same no-class-name check that keeps plain class-string and traits on the old path (a guard would be an equivalent mutant for Infection). This makes constant-string / class-string unions behave exactly like object-typed unions with respect to rule levels — per-member filtering when checkUnionTypes is off, whole-union check when it is on — and gives them the rest of the pipeline, including private/protected visibility.

• Class-strings whose object type has no class name (plain class-string, class-string<object>, class-string<T of object>) are not rerouted and stay silent, as before.
• Class-strings naming a trait are not rerouted either and stay silent, as before (RuleLevelHelper would report the trait as an unknown class).
• There is no hasConstant() guard: ConstantStringType::hasConstant() answers for the class it names, so such a guard would skip exactly the constant strings whose constant exists, and lose the private/protected checks.

defined() guards

Routing class-strings through the rule surfaced a common idiom that was only silent because of the bail-out:

if (defined($class . '::ENTITY_CLASSNAME')) {
	return $class::ENTITY_CLASSNAME;
}

DefinedConstantTypeSpecifyingExtension only narrowed a constant argument (defined('Foo::BAR') narrows Foo::BAR). It now also recognizes $expr . '::NAME', "$expr::NAME" and "{$expr}::NAME" when $expr is a string, and narrows $expr::NAME the same way, so the rule's existing hasExpressionType() check skips the guarded fetch and its type becomes mixed instead of *ERROR* (a constant that exists keeps its type). This is the shape behind the neos/flow integration failure (ReflectionService::completeRepositoryAssignments()). Unguarded access to a constant that only implementations declare, through a class-string<SomeInterface>, is still reported — consistently with $object::CONST on an interface-typed object.

::class handling

The class pseudo-constant is deliberately excluded from the conversion (strtolower($constantName) !== 'class'). $string::class is a runtime TypeError (Cannot use "::class" on string), unlike $object::class, and the rule already reports this as classConstant.dynamicString. Rerouting a class-string through its object type would suppress that error, so the pseudo-constant is left on the existing string code path. Pinning tests cover $constantStringUnion::class and class-string<Foo>::class, both of which keep emitting classConstant.dynamicString. defined("$class::class") is not narrowed.

Tests

New data file class-constant-string-unions.php mirrors #5976's matrix: single constant string, constant-string union with one member missing the constant, get_class() union, single class-string<C>, class-string union, plain class-string (silent), the two ::class pinning cases, enum-case access through both a constant string and a class-string<Enum>, private/protected constants through a constant string, trait name (silent), defined() guards in the three forms plus an unguarded access, and the neos/flow shape (defined($c . '::X') && isset($map[$c::X]) over class-string<SomeInterface>). Wired into ClassConstantRuleTest with checkUnionTypes on and off to pin level semantics, using the same flag-combination approach as the template.

nsrt/defined-dynamic-class-constant.php pins the narrowed types.

Ecosystem impact

The shopware integration test gets one new, correct error: HooksReferenceGenerator reads $hook::FUNCTIONS with $hook a class-string<InterfaceHook>, and the abstract InterfaceHook does not declare FUNCTIONS (only its subclasses do; the same access on an InterfaceHook object is already reported). Companion baseline update: phpstan/phpstan#15472. The neos/flow error seen on an earlier revision is gone thanks to the defined() narrowing described above.

Alternatives

If you prefer, any of these can go the other way, in line with whatever is decided on #5976:

• (a) gate unions on checkUnionTypes instead of routing through the object type; with the current choice, class-string unions follow the object-union rules (reported at level 7+ only).
• (b) mirror what T::CONST reports for a class-string naming a trait (Cannot access constant CONST on trait T.) instead of staying silent.
• (c) land the defined() narrowing as a separate PR before this one.

Companion PR (integration/e2e expectation, merge together): phpstan/phpstan#15477

🤖 Generated with Claude Code, model Fable 5.