Select local implicits over name-imported over wildcard imported

[dwijnand]

No description provided.

[som-snytt]

I haven't studied this issue, but intuitively, it's too bad to add special rules which are reminiscent of name-binding precedence, though implicit search was freed from naming and relied only on a notion of context depth.

I see the test is about implicits and not givens. I don't even remember if they are treated differently, aside from import syntax.

[dwijnand]

I haven't studied this issue, but intuitively, it's too bad to add special rules which are reminiscent of name-binding precedence, though implicit search was freed from naming and relied only on a notion of context depth.

There's some name shadowing still in play, for instance from tests/pos/Monoid.scala import Monoid.ops._; import Ring.ops.* wants Ring.ops.InfixAppend to shadow Monoid.ops.InfixAppend rather than be ambiguous with it.

Other than that, "all" I'm trying to do is deal with the unfortunate inversion that exists between the context for a method block scope being the "outer" context to the context that comes from encountering an import in the block. Rather than try to change that setup and everything that entails, I went with the fix that akin to checkNewOrShadowed.

I see the test is about implicits and not givens. I don't even remember if they are treated differently, aside from import syntax.

🙄 We need a new tools pragma // sed: s/implicit/given/ tests/run/i18183.scala.

[odersky]

Note that new style givens already work correctly. It's just old-style implicits that differ. In that light, we should not spend too much complexity for something that so far did not seem to cause a problem in practice.

[dwijnand]

Note that new style givens already work correctly. It's just old-style implicits that differ.

That's true, in as much as import bar._ doesn't import givens by default, so there's no chance of accidentally choosing it.
But import bar.{ given, * }, which would be the equivalent new way of doing it, and runs into exactly the same problem, even using givens.

[odersky]

Otherwise LGTM

[odersky]

Why the !migrateTo3 condition? I thought Scala 2 has the same preferences of definitions over imports?

[dwijnand]

To counter the fact that we're flattening it in "level". Otherwise we end up preferring the candidates in an outer scope, which should have a smaller level, over the ones in an inner scope.

I encountered it in CI, and minimised the problem to tests/pos/i18183.migration.scala. Because it runs under -source:3.0-migration then outer implicit F: Async[F] "shadows" inner implicit F: Async[M], making it impossible to call semiflatMap for lack of a Async[M] in scope.

[odersky]

I see. Yes that makes sense.