-
Notifications
You must be signed in to change notification settings - Fork 397
Force super classes to generate default bridges on lookup #4893
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
Conversation
Only the last commit is part of this PR. |
@sjrd what kind of benchmarking does this need? I suspect method lookup is quite performance sensitive? |
- Fixes scala-js#2520 (make default bridge generation smarter) - Avoids traversal order dependent behavior. Since we potentially need to do a default target check on every method lookup, we memoize calculated default targets. Note that this might generate more default bridges than actually necessary. However, since they will not be marked as reachable, they will not even be synthesized.
case Some(superClass) => tryLookupInherited(superClass) | ||
case None => None | ||
publicMethodInfos.get(methodName) match { | ||
case Some(m) if !m.isAbstract => Some(m) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This keeps the previous behavior w.r.t. abstract methods, but it seems this is a problem:
If we try to call a method on a class that is abstract, won't we replace the abstract method info with the missing method info? (similar thing with default methods, but its unclear to me ATM whether that can happen).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to be the case, yes. But it also doesn't seem to be an issue? Unless perhaps it adds more errors: trying to later call that method will report a missing declaration (because the abstract method is now missing). Is that what you're concerned about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might add more errors, yes. My main concern here is about determinism: It would not surprise me if the exact errors here depend on the call graph traversal order. But in any case, this is not something related to this PR.
One effective thing to measure is successive relinkings of the test suite. Using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good :)
No significant difference on 21 runs (1 batch run, 20 incremental runs). IMO good to merge. @sjrd WDYT? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 🙂
Since we potentially need to do a default target check on every method lookup, we memoize calculated default targets.
Note that this might generate more default bridges than actually necessary. However, since they will not be marked as reachable, they will not even be synthesized.