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

findOrCreateModuleVar picks the wrong symbol #5012

Closed
scabug opened this issue Sep 19, 2011 · 2 comments
Closed

findOrCreateModuleVar picks the wrong symbol #5012

scabug opened this issue Sep 19, 2011 · 2 comments
Assignees

Comments

@scabug
Copy link

@scabug scabug commented Sep 19, 2011

I was looking today at refchecks in order to learn how modules are transformed. In so doing I spotted a bug.

scalac wrongly tells there's an error in the following program (the program is OK, in fact):

class D { 
  object p // (program point 1) 
}  

class C { 
  def m: D = { 
    if("abc".length == 0) {
      object p       // (program point 2)
    }
    null 
  } 
}

Summary: eliminateModuleDefs(tree: Tree) wants to expand the ModuleDef at "program point 2".
As part of that, it invokes

  def findOrCreateModuleVar() = localTyper.typedPos(tree.pos) {
    lazy val createModuleVar = gen.mkModuleVarDef(sym)
    sym.owner.info.decl(nme.moduleVarName(sym.name.toTermName)) match {
      // In case we are dealing with local symbol then we already have
      // to correct error with forward reference
      case NoSymbol => createModuleVar
      case vsym     => ValDef(vsym)
    }
  }

with tree bound to that ModuleDef. Normal behavior would be to enter the case NoSymbol,
however it finds a vsym (surprisingly, for the lowering of another module, that in "program point 1").

The assumptions under which findOrCreateModuleVar are written appear to be:
(a) for a module owned by class, sym.owner.info is a ClassInfo and thus decl() on it looks up where intended.
(b) for a module owned by something else, that same lookup will be performed on an EmptyScope.

Assumption (b) proves wrong when sym.owner.info returns a NullaryMethodType. In that case, NullaryMethodType.decls delegates to resultType.decls. In our case, that resultType ("D") happens to have as member an object with the same name, but not the one we're looking for.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Sep 19, 2011

Imported From: https://issues.scala-lang.org/browse/SI-5012?orig=1
Reporter: @magarciaEPFL
Affected Versions: 2.9.2

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Sep 28, 2011

Commit Message Bot (anonymous) said:
(extempore in r25757) Fix bug in ModuleDef elimination.

Fixes corner case diagnosed by miguel. Closes #5012, no review.

@scabug scabug closed this Sep 28, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.