Backend fails compilation when a class referenced in a signature of a previously compiled superclass is absent from classpath #275
Milestone
Comments
|
The stack trace above is from the error in the wild. It seems my minimization isn't faithful, it crashes in |
|
Here's a correct repro: // A.scala
package sample {
class A1 {
def irrelevant: p1.p2.p3.DeleteMe = null
}
object A1 {
class A1_Inner
}
}
package p1 {
class LeaveMe
package p2 {
package p3 {
class DeleteMe
}
}
}// B.scala
package sample
class Test {
final class Inner extends A1.A1_Inner {
def foo = 42
}
def test = new Inner().foo
}@lrytz Do we need to compute |
|
In general yes, when a class (being compiled) has a reference to a nested class (from the classpath), we need it for emitting the corresponding BTW, I think your example is incomplete, where are |
|
@lrytz I've added the missing parts to the example. |
retronym
added a commit
to retronym/scala
that referenced
this issue
Nov 29, 2016
- Limit the strategy of unpickling an external reference to a
module class to a lookup of the module var to non-stub owners
in order to enable fall through to stub symbol creation.
Fixes scala/scala-dev#275
retronym
added a commit
to retronym/scala
that referenced
this issue
Nov 29, 2016
- Limit the strategy of unpickling an external reference to a
module class to a lookup of the module var to non-stub owners
in order to enable fall through to stub symbol creation.
Fixes scala/scala-dev#275
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the root cause of wix-incubator/accord#84
The unpickler does not create a stub symbol in
nestedObjectSymbolwhenowneris itself a stub symbol.Contrast this with the code just above
Relatedly, the backend could be more robust in the face of these errors with:
The text was updated successfully, but these errors were encountered: