From 90a98f7c41cfcfdb60dc25db5ac33d0d0ff10f99 Mon Sep 17 00:00:00 2001 From: Jason Zaugg Date: Sun, 9 Nov 2014 18:29:35 +1000 Subject: SI-5639 Fix spurious discarding of implicit import In Scala fa0cdc7b (just before 2.9.0), a regression in implicit search, SI-2866, was discovered by Lift and fixed. The nature of the regression was that an in-scope, non-implicit symbol failed to shadow an eponymous implicit import. The fix for this introduced `isQualifyingImplicit` which discards in-scope implicits when the current `Context`'s scope contains a name-clashing entry. Incidentally, this proved to be a shallow solution, and we later improved shadowing detection in SI-4270 / 9129cfe9. That picked up cases where a locally defined symbol in an intervening scope shadowed an implicit. This commit includes the test case from the comments of SI-2866. Part of it is tested as a neg test (to test reporting of ambiguities), and the rest is tested in a run test (to test which implicits are picked.) However, in the test case of SI-5639, we see that the scope lookup performend by `isQualifyingImplicit` is fooled by a "ghost" module symbol. The apparition I'm referring to is entered when `initializeFromClassPath` / `enterClassAndModule` encounters a class file named 'Baz.class', and speculatively enters _both_ a class and module symbol. AFAIK, this is done to defer parsing the class file to determine what inside. If it happens to be a Java compiled class, the module symbol is needed to house the static members. This commit adds a condition that `Symbol#exists` which shines a torch (forces the info) in the direction of the ghost module symbol. In our test, this causes it to vanish, as we only need a class symbol for the Scala defined `class Baz`. The existing `pos` test for this actually did not exercise the bug, separate compilation is required. It was originally checked in to `pending` with this error, and then later moved to `pos` when someone noticed it was not failing. --- test/files/run/t2866.check | 3 +++ test/files/run/t2866.scala | 44 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+) create mode 100644 test/files/run/t2866.check create mode 100644 test/files/run/t2866.scala (limited to 'test/files/run') diff --git a/test/files/run/t2866.check b/test/files/run/t2866.check new file mode 100644 index 0000000000..7f52da85fb --- /dev/null +++ b/test/files/run/t2866.check @@ -0,0 +1,3 @@ +t2866.scala:30: warning: imported `one' is permanently hidden by definition of value one + import A.one // warning: imported `one' is permanently hidden by definition of value one. + ^ diff --git a/test/files/run/t2866.scala b/test/files/run/t2866.scala new file mode 100644 index 0000000000..8059107583 --- /dev/null +++ b/test/files/run/t2866.scala @@ -0,0 +1,44 @@ +// for 2.7.x compatibility + +object A { + implicit val one = 1 +} + +object Test extends App { + + locally { + import A._ + locally { + // assert(implicitly[Int] == 1) // error: could not find implicit value for parameter e: Int. + // !!! Why one A.one? + // (I assume you mean: why _not_ A.one? A.one is shadowed by local one. + // but the local one cannot be used yet because it does not have an explicit type. + implicit val one = 2 + assert(implicitly[Int] == 2) + assert(one == 2) + } + } + + locally { + import A._ + implicit val one: Int = 2 + assert(implicitly[Int] == 2) + assert(one == 2) + } + + locally { + import A.one // warning: imported `one' is permanently hidden by definition of value one. + // !!! Really? + //assert(implicitly[Int] == 1) + implicit val one = 2 + assert(implicitly[Int] == 2) // !!! why not 2? + assert(one == 2) + } + + locally { + import A.{one => _, _} + implicit val two = 2 + assert(implicitly[Int] == 2) // not ambiguous in 2.8.0 nor im ambiguous in 2.7.6 + } + +} -- cgit v1.2.3