Hi @DanielEScherzer

Thanks for the review!

On the internal docs: i'd lean toward holding off for now. If the RFC doesn't pass, we'd just throw the prose away; if it does, the API/internals will likely shift between now and acceptance, and I'd rather not rewrite the doc multiple times along the way. Once the RFC lands (hoping it does), I'm happy to write a proper INTERNALS section in one go against the final shape. or do you think there's value in having something now? (for review?)

Hi @DanielEScherzer

Thanks for the review!

On the internal docs: i'd lean toward holding off for now. If the RFC doesn't pass, we'd just throw the prose away; if it does, the API/internals will likely shift between now and acceptance, and I'd rather not rewrite the doc multiple times along the way. Once the RFC lands (hoping it does), I'm happy to write a proper INTERNALS section in one go against the final shape. or do you think there's value in having something now? (for review?)

I was thinking that this would be for reviewers to understand the rest of the patch - you know it best, since you wrote it, but others could use a roadmap/overview. I don't even known where to start for giving an example of "something like ..." for this, so I'll give one for #16952 (which I know best because I wrote it)

For supporting attributes on constants

• the grammar for the language is adjust to allow attributes on constants, moving constant declarations into attributed_statement which can have (but doesn't need) attributes
• the AST is stored in the same list of children as the constants in the declaration, as the last child
• zend_compile_const_decl() will compile the attributes into a normal hashtable with zend_compile_attributes, and then emit a ZEND_DECLARE_ATTRIBUTED_CONST with a data znode where the data is a pointer to that table
• at runtime, the VM handler will call zend_constant_add_attributes() to add the attributes

For supporting the deprecated attribute specifically

• zend_constant_add_attributes() will flag the constant with CONST_DEPRECATED if the deprecated attribute is present
• the existing logic to emit deprecation warnings for deprecated internal constants is instead replaced with calls to the new zend_deprecated_constant() function which handles reading for attributes if present

Just to have an understanding of how all of the pieces fit together

Makes sense. Will add it tomorrow morning 👍🏼

I checked the failing CircleCI ARM job.

Current failure is only:

Zend/tests/generics/inheritance/diamond/trait_diamond_variadic.phpt

It prints the reflected type correctly:

param: string|int
is union: yes

and then segfaults when the merged trait method is called: (new C)->sink(1, "x", 2, "y").

I built the branch locally on macOS arm64 with debug + ZTS and the same test passes for me, both plain and with opcache enabled. So this looks more like Linux ARM / JIT / merged arg_info lifetime than a test expectation issue.

The useful split is probably to rerun that one test on the ARM worker with JIT disabled. If it only crashes with JIT, the bad path is likely the merged trait method clone being executable but not looking quite like a normal trait clone to the runtime/JIT.

@prateekbhujel reproduced it locally in aarch64 Ubuntu 24.04 Docker container. pushing a fix now :)

Opened it against the working branch here: carthage-software#2

Opened one more small PR against the working branch for a Reflection edge case I hit while testing transitive interfaces:

carthage-software#3

It fixes ReflectionClass::getGenericArgumentsForParentInterface() returning an empty list when the generic ancestor is reached through a non-generic intermediate interface/class.

Opened a small PR for the current CI failure here: carthage-software#4

The failing test was creating an inherited-method arg_info clone even though the method-level Box<O> return did not actually substitute any class-scope slot.

Opened another Reflection follow-up against the working branch: carthage-software#5

It fixes nested transitive interface args, e.g. Mid<X> extends Root<Box<X>> plus Concrete implements Mid<int> reflecting Box<X> instead of Box<int>. This is mainly for consumers relying on Reflection metadata rather than reparsing source.

Opened the concrete Reflection piece here: carthage-software#6

It keeps the current singular method alone, but adds an all-bindings view for tools that need to see cases like Foo, Foo from Reflection without reparsing source. It is stacked on #5 for now, so the diff should shrink once that one lands.

Is there anything new?

How is the current state?

Why wasn’t this PR approved?