You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
packageobjectp {
typeFoo=Int
}
packagep {
objectDingo { typeFoo=String }
traitBippy {
importDingo._defz:Fooz: 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: typemismatch;
found : p.Foo
(which expands to) Intrequired: Stringz: 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.
The text was updated successfully, but these errors were encountered:
@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.
As a single file, this doesn't compile:
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!
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.
The text was updated successfully, but these errors were encountered: