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

Compiler.parseTree not thread-safe #8030

Closed
scabug opened this issue Dec 4, 2013 · 7 comments
Closed

Compiler.parseTree not thread-safe #8030

scabug opened this issue Dec 4, 2013 · 7 comments

Comments

@scabug
Copy link

@scabug scabug commented Dec 4, 2013

According to the contract of Compiler.parseTree, no symbol should be entered in the returned tree. This ticket in the Scala IDE project proves the contract is broken.

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

Imported From: https://issues.scala-lang.org/browse/SI-8030?orig=1
Reporter: @dotta
Affected Versions: 2.11.0-M8

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@retronym said:

ase: <no phase>] Please file a ticket with the current stack trace at https://www.assembla.com/spaces/scala-ide/support/tickets
	at scala.tools.nsc.interactive.Global.assertCorrectThread(Global.scala:517)
	at scala.reflect.internal.Symbols$Symbol.rawInfo(Symbols.scala:1395)
	at scala.reflect.internal.Symbols$Symbol.isCoDefinedWith(Symbols.scala:2041)
	at scala.reflect.internal.Symbols$ClassSymbol$$anonfun$companionModule0$1.apply(Symbols.scala:3085)
	at scala.reflect.internal.Symbols$ClassSymbol$$anonfun$companionModule0$1.apply(Symbols.scala:3085)
	at scala.reflect.internal.Symbols$Symbol.filter(Symbols.scala:1788)
	at scala.reflect.internal.Symbols$Symbol.suchThat(Symbols.scala:1792)
	at scala.reflect.internal.Symbols$ClassSymbol.companionModule0(Symbols.scala:3085)
	at scala.reflect.internal.Symbols$ClassSymbol.companionModule(Symbols.scala:3087)
	at scala.reflect.internal.TreeGen.mkTuple(TreeGen.scala:289)
	at scala.tools.nsc.ast.parser.TreeBuilder.makeTupleTerm(TreeBuilder.scala:42)
	at scala.tools.nsc.ast.parser.TreeBuilder.stripParens(TreeBuilder.scala:47)
	at scala.tools.nsc.ast.parser.Parsers$Parser.parseOther$1(Parsers.scala:1475)
	at scala.tools.nsc.ast.parser.Parsers$Parser.expr0(Parsers.scala:1477)

Seems like we need to force a few lazies in Definitions to make this work.

// On presentation compiler startup
definitions.TupleClass.seq.foreach(sym => fullyInitializeSymbol(sym))
// same for any other symbols used by Parsers.

This workaround could be done in the IDE in the meantime.

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@retronym said:
Denys, could you please audit what parts of Definitions are touched by Parsers, and see if you can force them in the presentation compiler initialization?

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@densh said:
Sure.

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@dotta said:
@jason Thanks. I'll add TupleClass to this

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@retronym said:
You'll need to to that for the family of Tuple symbols, TupleClass.seq in master, or (1 to 22).map(TupleClass(_)) if you need to be compatible with 2.10 and 2.11.

And I would change that to fullyInitializeSymbol to be on the safe side as you have the tuple class, module, and module class symbols to worry about.

@scabug
Copy link
Author

@scabug scabug commented Dec 4, 2013

@dotta said:
TupleClass.seq seems to exist on 2.10.4. Here is a link to the PR on Scala IDE, feel free to comment on it scala-ide/scala-ide#595

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants