Scala partially qualified symbol not inferred

[stuhood]

Code like:

import akka.http.javadsl.{ model => jm }

sealed trait ContentRange extends jm.ContentRange ... {

...will not infer a dependency on the symbol akka.http.javadsl.model.ContentRange.

[stuhood]

This represented roughly 12% of the issues in akka-http.

[stuhood]

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 (val lib = ...) and using a relative import (import x.lib).

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 alias field to our import definition which would record the import's scope-specific name (to handle the case in the description), and then emitting potentially consumed symbols for any consumed_symbols which are relative to (i.e., start-with) any in-scope import aliases. Thoughts @tdyas , @chrisjrn ?

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).

[tdyas]

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.