Skip to content

Wrong linearization for super calls in case classes #17555

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

Closed
ddtthh opened this issue May 22, 2023 · 3 comments · Fixed by #17574
Closed

Wrong linearization for super calls in case classes #17555

ddtthh opened this issue May 22, 2023 · 3 comments · Fixed by #17574
Labels
area:typer itype:bug regression This worked in a previous version but doesn't anymore
Milestone

Comments

@ddtthh
Copy link
Contributor

ddtthh commented May 22, 2023

Compiler version

3.2.2
3.3.0-RC3
Worked in 3.1.2

Minimized code

class Root {
  override def toString() = "Root"
}
trait A extends Root with B {  }
trait B {
   override def toString() = "B"
}
case class C() extends A {
  override def toString() = super.toString()
}

println(C())

Output

Root

Expectation

toString in trait B should be called and output should be B.
This works for normal classes, but the case class breaks that.

@ddtthh ddtthh added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels May 22, 2023
@szymon-rd szymon-rd added area:typer and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels May 23, 2023
@szymon-rd
Copy link
Contributor

Regression, behavior changed in 3.2.0-RC1

@szymon-rd szymon-rd added the regression This worked in a previous version but doesn't anymore label May 23, 2023
@szymon-rd
Copy link
Contributor

szymon-rd commented May 23, 2023

Bisected to first bad commit 16b8e07f189610fd620c1ab9f93f9e78643b36ca - #15416
@anatoliykmetyuk

@odersky
Copy link
Contributor

odersky commented May 24, 2023

@szymon-rd Thanks for the bisect! That would have been much harder to diagnose otherwise.

odersky added a commit that referenced this issue May 25, 2023
I am not quite sure about he previous definition of superType in
SuperType. I believe it's probably needed for something. But it's
clearly wrong if the `supertpe` argument does not have a symbol. We now
fall back to the default
```
   def superType = underlying
``` 
in this case.

Fixes #17555
@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:typer itype:bug regression This worked in a previous version but doesn't anymore
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants