-
Notifications
You must be signed in to change notification settings - Fork 132
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
Better detection of circular references #1165
Comments
The handling of this kind of feels related to #69 (finding more than one unique symbol). If e.g. exceptions are decided to be used I could try to implement that too. |
Unsure about how this one should be handled. #69 is about "locating" sources, while this one is about circular references in general. What happens if you have I don't think we should complicate this for code that is invalid upfront. Note that BetterReflection already crashes on code that cannot be parsed. |
Right, those 2 issues are not related much. I only thought both could lead to exceptions thrown. With The argument about invalid code is understandable. I thought Better Reflection should be able to somehow handle all code that is valid in terms of it can be parsed. With having static code analysis using Better Reflection in mind that made sense to me. But yeah, this code will lead to a fatal error if being executed and trying to handle this might add complexity here. |
Any new ideas here? I didn't come up with anything so far.. The question is: should BR detect this or not? |
IMO put it in a failing test PR first. Then discuss from there. |
Hi,
indirectly, via phpstan user report, I found out that there is valid PHP code that triggers endless recursion in Better Reflection.
E.g. circular class or interface extends statements like
This code will parse just fine, but lead to errors like
Class "TestClass" not found
, see https://3v4l.org/YIQNlThere are currently 2 cases for that specific example that I found that are problematic
ReflectionClass::getParentClass()
will never return null and consumers can recurse forever. This is kind of expected IMO and fixing it screams BC break or am I wrong?ReflectionClass::getInheritanceClassHierarchy()
, which in term uses getParentClass to find the root parent, leads to endless recursion. E.g.ReflectionClass::getInterfaces()
, IMO this could be already "fixed" without a BC break? But if getParentClass would be able to deal with it then nothing needs to be done here additionally I assume.The second one would be easy to prevent in Better Reflection directly, I did not dig deep enough yet to have an idea for the first one. And by preventing I mean something as throwing a
CircularReferenceException
, or do you have any better ideas?Ondrej also mentioned potential other problematic things via phpstan/phpstan#7787 (comment) and phpstan/phpstan#7787 (comment)
What do you think? Looking forward to your opinions. Also, I'm happy to work on anything related to this.
The text was updated successfully, but these errors were encountered: