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

identical code compiles in separate source files, fails in single source file #9552

Closed
scabug opened this issue Nov 10, 2015 · 4 comments
Closed
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Nov 10, 2015

As a single file, this doesn't compile:

package object p {
  type Foo = Int
}
package p {
  object Dingo { type Foo = String }
  trait Bippy  {
    import Dingo._
    def z: Foo
    z: String
  }
}
// s1/a.scala:8: error: reference to Foo is ambiguous;
// it is both defined in package object p and imported subsequently by
// import Dingo._
//     def z: Foo
//            ^
// one error found

However if that code is placed in two separate files, one for the package object and one for the rest, it compiles. I emphasize this is not a separate compilation bug - in both cases all the source code is being given to the compiler. The ONLY difference is the number of source files.

There is an additional problem. If we move import Dingo._ up one line so it is outside of Bippy, then the two-file variation no longer compiles, but not due to identifier ambiguity!

s2/b.scala:6: error: type mismatch;
 found   : p.Foo
    (which expands to)  Int
 required: String
    z: String
    ^
one error found

Notice it goes from resolving Foo one way to resolving Foo the other way after the minimum possible change. Sanity suggests the minimum change must be rendered ambiguous at one point or the other, as of course it is in the single-file case.

@scabug
Copy link
Author

@scabug scabug commented Nov 10, 2015

Imported From: https://issues.scala-lang.org/browse/SI-9552?orig=1
Reporter: @paulp
Affected Versions: 2.12.0-M3
Duplicates #2458

@scabug
Copy link
Author

@scabug scabug commented Feb 1, 2016

@som-snytt said (edited on Aug 18, 2016 9:07:36 PM UTC):
This is almost as per spec.

In the same scope, a higher-precedent binding shadows a lower-precedent.

In a nested scope, an inner-scoped binding shadows same-or-lower in an outer scope.

In the first example, Dingo._ is lower precedent than p.Foo in same unit, so doesn't shadow; but Dingo._ is higher precedent than p.Foo in different unit so it does shadow.

In the second example, at the same scope, p.Foo in the same unit is higher-precedent and shadows as shown; but Dingo._ should shadow p.Foo in different unit, which it does not in the implementation.

Also, s/shadows/hides.

@scabug
Copy link
Author

@scabug scabug commented Aug 18, 2016

@som-snytt said:
The fix for the related issue doesn't fix the "additional problem", with the import at package scope.

@scabug
Copy link
Author

@scabug scabug commented Aug 18, 2016

@som-snytt said:
Fixes wildcard import competing with foreign definition.

scala/scala#5339

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

Successfully merging a pull request may close this issue.

3 participants