Skip to content
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

SI-9881 Fix ImportHandler's reporting of importedNames and importedSymbols #5326

Closed
wants to merge 4 commits into from
Closed

SI-9881 Fix ImportHandler's reporting of importedNames and importedSymbols #5326

wants to merge 4 commits into from

Conversation

jasonxh
Copy link
Member

@jasonxh jasonxh commented Aug 10, 2016

This PR attempts to fix importedNames and importedSymbols in ImportHandler. Currently they are broken, causing the following issues:

Changes in this PR:

  • Keep track of both selector names & renames. Use names to lookup symbols from owner. Use renames to construct importedNames.
  • sym.thisType will never work for module symbols. Change to sym.typeOfThis sym.moduleClass.thisType.
  • Fix the bug where typeOfExpression inadvertently resolves type under jvm phase, disregarding requested phase from caller. This is used in ImportHandler to find importableMembers from objects.
  • Cherry-picked @retronym 's change from https://github.com/retronym/scala/tree/review/4698 to filter out flattened inner symbols from importableMembers.

@scala-jenkins scala-jenkins added this to the 2.11.9 milestone Aug 10, 2016
@jasonxh
Copy link
Member Author

jasonxh commented Aug 24, 2016

@retronym I cherry-picked some of your changes from https://github.com/retronym/scala/tree/review/4698 to filter out flattened symbols. It seems there hasn't been activity in that branch in the past year. Are you still working on it? If there is pending work in the area, please let me know and we can coordinate that.

@retronym
Copy link
Member

Thanks for picking this up. My branch is dormant, I'm not currently working on this.

@retronym retronym changed the title [SI-9881] Fix ImportHandler's reporting of importedNames and importedSymbols SI-9881 Fix ImportHandler's reporting of importedNames and importedSymbols Aug 24, 2016
@jasonxh
Copy link
Member Author

jasonxh commented Sep 20, 2016

@retronym can you help review this PR, especially the changes I cherry-picked from your branch?

Copy link
Contributor

@adriaanm adriaanm left a comment

Choose a reason for hiding this comment

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

There are some solid improvements in here, thank you! I know it's been too long, but could you take a look at a few of my suggestions? To avoid test failures, I'd suggest moving the fix for index of out bounds in names first, and squashing the WIP commit into your own.

@@ -4549,7 +4549,12 @@ trait Types

/** Members which can be imported into other scopes.
*/
def importableMembers(pre: Type): Scope = pre.members filter isImportable
def importableMembers(pre: Type): Scope = {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this change is too risky for 2.11.9. How about moving it to the invocation of importableMembers in the repl?

Copy link
Member Author

Choose a reason for hiding this comment

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

Will move to MemberHandlers

}
private def importableTargetMembers = importableMembers(targetType).toList
private def importableTargetMembers = importableMembers(exitingTyper(targetType)).toList
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this PR introduce any new call-sites of importableTargetMembers that aren't already in exitingTyper?

Currently, IntelliJ says:

    lazy val individualSymbols: List[Symbol] = exitingTyper(importableTargetMembers filter (m => selectorNames(m.name)))
    lazy val wildcardSymbols: List[Symbol]   = exitingTyper(if (importsWildcard) importableTargetMembers else Nil)

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope it doesn't introduce new call sites. I just moved exitingTyper from both call sites to importableMembers itself.

@@ -214,27 +214,34 @@ trait MemberHandlers {
val Import(expr, selectors) = imp
def targetType = intp.global.rootMirror.getModuleIfDefined("" + expr) match {
case NoSymbol => intp.typeOfExpression("" + expr)
case sym => sym.thisType
case sym => sym.moduleClass.thisType
Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch!

    /** If symbol is a class, the type `this.type` in this class,
     * otherwise `NoPrefix`.
     * We always have: thisType <:< typeOfThis
     */
    def thisType: Type = NoPrefix

From the repl's :power mode:

scala> object o
defined object o

scala> val module = typeOf[o.type].termSymbol
module: $r.intp.global.Symbol = object o

scala> module.thisType
res7: $r.intp.global.Type = <noprefix>

scala> module.moduleClass.thisType
res8: $r.intp.global.Type = o.type

However, this can be had more directly:

scala> module.tpe
res12: $r.intp.global.Type = o.type

Copy link
Member Author

Choose a reason for hiding this comment

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

Will use the simpler version.


// non-wildcard imports
private def individualSelectors = selectors filter { x =>
x.name != nme.USCOREkw && x.name != null && x.rename != nme.USCOREkw & x.rename != null
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we encapsulate this stuff in Contexts, say? Looks like we already have warnUnusedImports, which compares against the more logical nme.WILDCARD, by the way.

Copy link
Member Author

Choose a reason for hiding this comment

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

Will create some helpers in Contexts.

@adriaanm
Copy link
Contributor

adriaanm commented Jan 5, 2017

Ping! If you'd like this to be considered for 2.11.9, please let us know by the end of the week and we'll do our best to help you get this over the finish line.

@adriaanm
Copy link
Contributor

adriaanm commented Jan 9, 2017

Please consider resubmitting for 2.12.2!

@adriaanm adriaanm closed this Jan 9, 2017
@jasonxh
Copy link
Member Author

jasonxh commented Jan 12, 2017

@adriaanm Sorry I didn't get back to this in time. I'll rebase against 2.12.x and address your comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants