-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Scala partially qualified symbol not inferred #13740
Comments
This represented roughly 12% of the issues in |
It seems like completely solving this would amount to implementing symbol resolution such that we could differentiate between using a field of a local variable ( But since we do not need 100% accuracy here, it seems like an imports-only-aware bit of resolution would be feasible. To do that, I'm thinking of adding an Also, while it's been useful to have more data emitted as JSON to Python, it occurs to me that we could be doing ~all of the consumed symbols calculations inline in the parser (or at least, before emitting JSON). |
That gets into partial type solving which is something that I had looked into a little but punted on as JavaParser’s existing code wants to completely type solve and it would’ve required a fair bit of work to try and do partial type solving. For Scala, I never got the chance to see what scalameta had for type solving. Definitely a path that we had considered earlier but could be a fair bit of work. |
Relative imports are common in Scala, and not supporting them caused ~12% of the issues in our test repository. See #13740 for background. To support them, compares the final token of an import (or its alias, if it has one) to the first token of any multi-token symbol that is scoped below the import. Fixes #13740.
Code like:
...will not infer a dependency on the symbol
akka.http.javadsl.model.ContentRange
.The text was updated successfully, but these errors were encountered: