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

Clarify spec for package syms #2458

Closed
scabug opened this issue Oct 9, 2009 · 14 comments · Fixed by scala/scala#6589
Closed

Clarify spec for package syms #2458

scabug opened this issue Oct 9, 2009 · 14 comments · Fixed by scala/scala#6589

Comments

@scabug
Copy link

scabug commented Oct 9, 2009

According to SLS ch. 2 second para,

"Bindings of different kinds have a precedence defined on them: Definitions (local or inherited) have highest precedence, followed by explicit imports, followed by wildcard imports, followed by package members, which have lowest precedence."

However, scalac (both 2.7.x and trunk) behave differently as illustrated,

A.scala:

package p

class BitSet

B.scala

package p

import scala.collection.BitSet

object Test {
 val b : BitSet = new scala.collection.mutable.BitSet
}

scalac produces the following output,

B.scala:3: warning: imported BitSet is permanently hidden by definition of class BitSet in package p
import scala.collection.BitSet
       ^
B.scala:6: error: type mismatch;
 found   : scala.collection.mutable.BitSet
 required: p.BitSet
 val b : BitSet = new scala.collection.mutable.BitSet

indicating that the package-local definition p.BitSet has taken precedence over the explicit import of scala.collection.BitSet in B.scala.

The spec and the compiler should agree, and arguably the specified behaviour makes more intuitive sense than the current actual behaviour.

@scabug
Copy link
Author

scabug commented Oct 9, 2009

Imported From: https://issues.scala-lang.org/browse/SI-2458?orig=1
Reporter: @milessabin
Affected Versions: 2.9.3, 2.10.3, 2.11.0-RC1

@scabug
Copy link
Author

scabug commented Oct 27, 2009

@odersky said:
I tried to change the behavior to match the spec, but lots of code broke, so I backed out and made the spec conform to current behavior. It now reads:

Bindings of different kinds have a precedence defined on them:
Definitions and declatarations have the highest precedence, no
matter whether they are local, or inherited, or made available by a
package clause. Explicit imports have the next highest precedence and
wildcard imports have the lowest precedence.

@scabug
Copy link
Author

scabug commented Dec 17, 2012

@Blaisorblade said:
The bug seems still there, though in a different form as the spec text is much more complicated now. In particular, a definition in compilation unit A made available in compilation unit B has topmost priority right inside the packaging, even though the spec claims it has the lowest priority, but it has indeed the lowest priority (as specified) inside any object nested in the packaging.
https://groups.google.com/d/topic/scala-internals/-Rquc2HBYLk/discussion

@scabug
Copy link
Author

scabug commented Aug 26, 2013

@retronym said:
Here's an example of why we need to update the spec: http://youtrack.jetbrains.com/issue/SCL-5848

@scabug
Copy link
Author

scabug commented Sep 24, 2013

@retronym said:
Further discussion: scala/scala-dist#96

@scabug
Copy link
Author

scabug commented Mar 13, 2014

@retronym said:
scala/scala#3626

@scabug
Copy link
Author

scabug commented Mar 14, 2014

@retronym said:
Quoth @adriaanm

I'd rather introduce this in 2.11.1 under -Xsource:2.12 / -Xfuture. We shouldn't have RC2 break code that compiled in RC1 unless warranted by some serious regression.

@scabug
Copy link
Author

scabug commented May 8, 2014

@retronym said:
Before we close this ticket, we should also add a clarification to the spec along the lines of:

https://issues.scala-lang.org/browse/SI-8559?focusedCommentId=69367&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-69367

@scabug
Copy link
Author

scabug commented Aug 5, 2014

@gkossakowski said:
The 2.11.2 is out so I'm rescheduling the issue for 2.11.3.

@scabug
Copy link
Author

scabug commented Nov 4, 2014

@retronym said:
Updating fix-by version to 2.11.5.

@scabug
Copy link
Author

scabug commented May 30, 2016

@milessabin said:
I'm not clear what the current consensus on this is now: is the spec correct and the compiler in error? Or vice versa?

@scabug
Copy link
Author

scabug commented May 30, 2016

@som-snytt said:
I'll update Jason's branch and submit it to fix the implementation.

The spec help is scala/scala#5151

@scabug scabug closed this as completed Jun 22, 2016
@scabug
Copy link
Author

scabug commented Jun 24, 2016

@som-snytt said:
This was closed without Jason's rework-in-progress at https://github.com/som-snytt/scala/tree/ticket/2458 for the bug part.

@scabug
Copy link
Author

scabug commented Aug 18, 2016

@som-snytt said:
The PR is scala/scala#5339.

Note that it doesn't yet fix the pernicious package object paulpism at #9552.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants