-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
A foreign definition induces ambiguity #7609
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I imagine he would scrawl with a sharpie: "LGTM! -- J" |
PR title by Edward Gorey |
I see @hrhino did a similar refactor, for a different purpose, so it's not an easy rebase. |
A foreign definition can't shadow a definition in the current unit. Also, an import that could shadow the foreign definition can't shadow the definition in the current unit.
@hrhino I had wanted encapsulation for that save/restore state, so I had a The gist here is that just as it has to go looking for an ambiguating import, it has to go looking for an ambiguating definition if the definition we have is "defined in a different compilation unit", precedence level 4. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks right to me, but who can say? I may have changed this code, but I never claimed to understand it.
Do other people really write packagings this way? I'm glad this wound up being an error, because if you showed me px_2.scala
and asked me what happens, I'd have to admit my insufficient Scala understanding. Does the puzzlers guy accept temporary puzzlers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<font face="sharpie sans">
LGTM --a </font> <!-- CSS who? -->
Does this need a forward port to dotty? |
I created a ticket for Dotty, and discovered that it picks |
I've noticed this bug fix comes up quite frequently when migrating 2.12 code bases to 2.13. For the record here's a canonical example: // /tmp/test.scala
package p1 {
class C {
def c_p1 = ""
}
}
package p2 {
class C {
def c_p2 = ""
}
} package p2 {
import p1._
class test {
new C().c_p2
}
}
A cross compatible version of package p2 {
import p1.{C => _, _}
class test {
new C().c_p2
}
} IntelliJ's presentation compiler works implements both the old and new behaviour, choosing which one based on the current Scala version: JetBrains/intellij-scala@a427c20 |
The Dotty ticket is scala/scala3#8059 3.x is same as 2.13 for the canonical example. I commented on the Dotty ticket that for these tests, Dotty picks
|
A foreign definition can't shadow a definition
in the current unit. Also, an import that
could shadow the foreign definition can't
shadow the definition in the current unit.
Fixes scala/bug#10662