Skip to content

Fix bug #69180 (Reflection does not honor trait conflict resolution / method aliasing) #5226

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

nikic
Copy link
Member

@nikic nikic commented Mar 2, 2020

Currently, trait methods are aliased will continue to use the original function name. In a few places in the codebase, we will try to look up the actual method name instead. However, this does not work if an aliased method is used indirectly (https://bugs.php.net/bug.php?id=69180).

I think it would be better to instead actually change the method name to the alias. This is in principle easy: We have to allow function_name to be changed even if op array is otherwise shared (similar to static_variables). This means we need to addref/release the function_name separately, but I don't think there is a performance concern here (especially as everything is usually interned).

There is a bit of complication in opcache, where we need to make sure that the function name is released the correct number of times (interning may overwrite the name in the original op_array, but we need to release it as many times as the op_array is shared).

@@ -25,5 +25,5 @@ array(2) {
[0]=>
string(10) "testMethod"
[1]=>
string(25) "testmethodfromparenttrait"
string(25) "testMethodFromParentTrait"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is solving https://bugs.php.net/bug.php?id=74939, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it, thanks for pointing it out.

@dstogov
Copy link
Member

dstogov commented Mar 3, 2020

In general, I like this.
The decision, taken in zend_persist[_calc], is not obvious, but I don't see a simpler solution.
Please add comments for last chunks of zend_persist[_calc].

@php-pulls php-pulls closed this in 53efa1b Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants