Tag: Branch: Tree: e4d8cbb798

master

speed_build

v0.0.1

v0.0.2

v0.0.3

v0.0.4

v0.0.5

v0.0.6

v0.0.7

v0.1.0

v0.4.0

v0.4.1

v0.6.1

v0.6.2

v0.6.5

v0.6.6

v0.6.8

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from 'e4d8cbb798'

${ noResults }

Commit Graph

1 Commits (e4d8cbb798f270a8477ac406ca634e12842bbf3a)

Author	SHA1	Message	Date
Alessio Giacobbe	fafd7f25dc	fix: enforce readonly declaration and inheritance rules (#66) ... * fix(preprocessor): enforce Zend readonly property declaration rules The readonly checks previously lived only in the Native-class branch; ZendVM-backed classes accepted declarations Zend rejects at compile time. addClassProperty now enforces, for declared and promoted properties alike (probed against Zend 8.4.13): - readonly property with a default value ("Readonly property A::$x cannot have default value") - a readonly property carries runtime initialization state, so a compile-time default is meaningless - untyped readonly property, including untyped promoted readonly ctor params ("Readonly property A::$x must have type") - static readonly ("Static property A::$x cannot be readonly") - a `readonly class` applies the same three rules to every property: the class-level Modifiers::READONLY flag (already recorded on ClassDef->flags for the Translator-side inheritance check) is OR-ed into the per-property check Promoted readonly params keep accepting parameter defaults: the default belongs to the constructor argument, not the property (Zend-verified). The inheritance_error_prop_readonly fixture used `readonly int $x = 2`, which Zend itself rejects with the default-value error before ever reaching the readonly-mismatch link error; the default is dropped so the fixture still exercises the inheritance mismatch. * fix(translator): enforce readonly-class inheritance in both directions Zend seals readonly-ness across a hierarchy: a non-readonly class cannot extend a readonly one and vice versa. Both directions compiled silently. * fix(translator): complete readonly-class contracts for traits, internal parents and attributes Three readonly-class rules Zend enforces at compile time were still accepted (all probed on 8.4.13): - A trait property keeps its own declaration; the consuming class's readonly modifier does not upgrade it, so composing a non-readonly (or static, which can never be readonly) trait property into a readonly class fails: "Readonly class C cannot use trait with a non-readonly property T::$value". The check runs in composeTraitAst's property pass, which also matches Zend's naming of the directly used trait when the property originates in a nested trait. A trait property declared readonly composes fine. - The readonly inheritance check only covered compiled parents; classes extending internal ones skipped it entirely, so `readonly class C extends ArrayObject {}` compiled. Internal parents now consult host reflection (ReflectionClass::isReadOnly), keeping the contract two-directional: the host runtime also knows internal readonly classes (BcMath\Number, Dom\NamespaceInfo — both final in 8.4, so only the readonly-child direction is reachable today). - #[AllowDynamicProperties] contradicts readonly semantics (every property is readonly and declared); Zend rejects the combination: "Cannot apply #[AllowDynamicProperties] to readonly class C". The pre-existing readonly-class.phpt carried exactly this invalid combination and is adjusted to stay a valid positive test.	2 days ago