-
Notifications
You must be signed in to change notification settings - Fork 21
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
crasher in mixins under -optimize in a REPL setting #5789
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5789?orig=1 |
@retronym said: class ScalaColls(n: Int) {
() => n
} The REPL crashes every second time it sees this. |
@magarciaEPFL said: |
@magarciaEPFL said:
The only difference In other words
to:
|
@SethTisue said (edited on Jun 14, 2012 5:38:11 PM UTC):
the exact details don't seem to matter here (you can substitute Stream for List, String for Int, fold for reduce, etc.) the same bug, or maybe just closely related? |
@jsuereth said: |
@retronym said: |
@retronym said (edited on Jun 14, 2012 9:01:31 PM UTC):
[log erasure(->posterasure ->posterasure)] Creating implClass for trait Function2#1114
[log erasure(->posterasure ->posterasure)] trait Function2#1114.implClass already exists: class Function2$class#787
[log erasure(->posterasure ->posterasure)] unlinking impl class class Function2$class#787
[log erasure(->posterasure ->posterasure)] Creating implClass for trait Function2$mcIII$sp#48400
[log erasure(->posterasure ->posterasure)] trait Function2$mcIII$sp#48400.implClass already exists: class Function2$mcIII$sp$class#922
[log erasure(->posterasure ->posterasure)] unlinking impl class class Function2$mcIII$sp$class#922 But later, the original symbol turns up, stripped of its mixinImplClassMembers(mixinClass = class Function2$class#787, mixinInterface = trait Function2#1114)
mixinClass.isImplClass = false |
@paulp said (edited by @adriaanm on Jul 3, 2012 9:21:03 AM UTC):
I dropped that comment in paulp/scala@e2951867f which is probably something to look at. |
@gkossakowski said: http://www.sumologic.com/blog/technology/3-tips-for-writing-performant-scala Would be great to fix it by 2.10. |
Alan Burlison (alanbur) said (edited on Aug 9, 2012 10:03:06 AM UTC): |
@JamesIry said: Now investigating Paul's earlier comment about the IMPLCLASS flag's behavior under -optimize. |
@JamesIry said: The assert that's failing is doing a sanity check - we should only be putting mixin forwarders to a mixin impl class. Reasonable, no? The problem is that in this case the flag is lying. And it's lying because of our old friend lazy initialization. Paul's innocuous refactoring of Mixin.scala removed an initialization that was there before. It turns out that the easy fix is to get rid of the assert. Everything works without. But the interesting story here, IMO, is why this particular lie only happens in the REPL under optimize (actually REPL with -Yinline is sufficient). The answer is that the REPL does a separate compilation for each line but keeps some state lying around between compilations. In fact, it can be replicated by using fsc -Yinline to do two separate compilations because fsc also leaves some stuff lying around. Exactly what is being left around is a bit fuzzy to me. We're ending up with two symbols representing the same thing, one with the flag set and one that's not been initialized. Why only -Yinline? That's a bit fuzzier. And I'm investigating. It's possible it's something to do with class parsing being slightly different under optimization, but I doubt it. My stronger suspicion is that the inliner is responsible for leaving the uninitialized symbol lying around. |
@gkossakowski said: Getting rid of the assert is not real fix, though. It's just hiding the fact that we get into inconsistent state and the rest of the code can recover from it by accident. However, that kind of issues are killing us every time we want to enable resident compiler in sbt/ide which we really want for fast incremental compilation cycles. Therefore, we really need to understand the root cause for this issue and fix it. |
@retronym said: |
@JamesIry said: |
@adriaanm said: |
Given:
This compiles under:
The glorious crash dump runs like this:
My attempts to reproduce the issue outside of the REPL by mimicing its wrapper objects failed:
The text was updated successfully, but these errors were encountered: