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
Specialized classes with lazy vals generate broken variants #5552
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5552?orig=1
|
@non said: It actually turns out that the LAZY flag was being masked by the specialization phase (Paul Phillips helped diagnose this). I'll try to find the patch which turns this off. Once you fix this, things break farther down the line, and I haven't had much time to spend on it. |
@non said: As I said in the last comment, the LAZY flag was being removed. In addition, the ACCESSOR flag was also being removed. Once I got those fixed, I moved on to the next error (I have attached a patch that fixes that issue). At that point, the problem is that C$mcI$sp.b$mcI$sp() isn't given the same "lazy method" block that C.b() has. This causes a MatchError in the mixin phase later. Compare: // generic b() is fine
class C ... {
<method> <stable> <accessor> lazy <triedcooking> def b(): scala.this.Tuple2[A,A] = {
C.this.b = new scala.this.Tuple2[A,A].<init>(C.this.a, C.this.a);
C.this.b
};
}
// specialized b$mcI$sp() is broken
class C$mcI$sp ... {
<method> <stable> <accessor> lazy <specialized> <triedcooking> def b$mcI$sp(): scala.this.Tuple2[scala.this.Int,scala.this.Int] = C$mcI$sp.this.b$mcI$sp;
} I think that if we can get the body of b$mcI$sp() to look more like the body of b(), which really just means assigning a tuple to the b$mcI$sp field, then things might work. Looking into this further. |
@non said: |
@non said: At this point I think the ACCESSOR flag is confusing other parts of specialization. Namely, we need to be saving and copying over the method def, but instead we're treating this like other simple accessors. I'm still looking into how to fix this. |
@non said: Sending a pull request to Github now. |
@non said: |
@adriaanm said: |
Here's the test case:
Expected output:
Actual output:
The problem seems to be that the specialized subclass doesn't get its own bitmap... it just assumes its lazy val field has already been initialized. I'm not really an expert on lazy val, but barring deeper changes (e.g. not duplicating vals between generic class and specialized subclass) I think we need to copy the bitmask and the code in b that checks it.
The text was updated successfully, but these errors were encountered: