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

Avoid crash in erasure when reference cannot be emitted #18056

Merged
merged 2 commits into from
Jul 3, 2023

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 25, 2023

Fixes #17391

@odersky odersky added the fasttrack Simple fix. Reviewer should merge or apply additional changes directly. label Jun 26, 2023
@dwijnand
Copy link
Member

Wait, why does can y.retainAll compile but x.f.retrainAll can't? Looks like either both should or both shouldn't - I don't see why they're different.

@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

x.f's type is erased to Object and is then downcast to Bar in erasure. That cast cannot be expressed since Bar is not visible.

@dwijnand
Copy link
Member

Bar is visible, it's only Base which isn't.

@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

Bar is visible, it's only Base which isn't.

Indeed. I guess it tries to cast to Base, not Bar, since that's the owner of retainAll. What does Scala 2 do?

@dwijnand
Copy link
Member

dwijnand commented Jun 26, 2023

Just uses Bar, it looks like

[[syntax trees at end of                   erasure]] // test.scala
      val x: Foo = new Foo(new mypkg.Bar());
      val y: mypkg.Bar = new mypkg.Bar();
      y.retainAll("fd");
      x.f().$asInstanceOf[mypkg.Bar]().retainAll("fd")

@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

Can you find out why it tried to refer to the inaccessible class?

The original qualifier type was computed in the wrong context. For the logic
to make sense, it needs to compute the type before erasure and then erase that
type. That fixes scala#17391 by now compiling it correctly, the same way Scala 2 does.
@odersky odersky removed the fasttrack Simple fix. Reviewer should merge or apply additional changes directly. label Jun 26, 2023
@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2023

You were right. There was another, deeper issue that caused the problem. See last commit.

@odersky odersky merged commit 347a567 into scala:main Jul 3, 2023
@odersky odersky deleted the fix-17391 branch July 3, 2023 21:58
@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
Kordyjan added a commit that referenced this pull request Dec 8, 2023
… LTS (#19056)

Backports #18056 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
@Kordyjan Kordyjan modified the milestones: 3.4.0, 3.3.2 Dec 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MatchError when calling a public method inherited from a default class
3 participants