package-private methods still ambiguate implicit conversions

[armanbilge]

Reproduction steps

//> using scala "2.13.11-bin-f3bd333"

package foo {

  trait Baz[A]
  object Baz {
    implicit def instance[A]: Baz[A] = ???
  }

  package syntax {
    object all {
      implicit def ops1[A: Baz](a: A): BarOps1 = new BarOps1(a)
      implicit def ops2[A: Baz](a: A): BarOps2 = new BarOps2(a)
    }

    class BarOps1(val a: Any) extends AnyVal {
      def bar(x: Int): String = ???
    }

    class BarOps2(val a: Any) extends AnyVal {
      private[syntax] def bar(x: Int): String = ???
    }
  }
}

import foo.syntax.all._

object Main {
  def main(args: Array[String]): Unit = {
    val a = new Object
    a.bar(42)
  }
}

Problem

[error] ./bug.scala:31:5: type mismatch;
[error]  found   : a.type (with underlying type Object)
[error]  required: ?{def bar(x$1: ? >: Int(42)): ?}
[error] Note that implicit conversions are not applicable because they are ambiguous:
[error]  both method ops1 in object all of type [A](a: A)(implicit evidence$1: foo.Baz[A]): foo.syntax.BarOps1
[error]  and method ops2 in object all of type [A](a: A)(implicit evidence$2: foo.Baz[A]): foo.syntax.BarOps2
[error]  are possible conversion functions from a.type to ?{def bar(x$1: ? >: Int(42)): ?}
[error]     a.bar(42)
[error]     ^
[error] ./bug.scala:31:5: value bar is not a member of Object
[error]     a.bar(42)
[error]     ^^^^^

This reproducer is a revival of #12578, which was solved as originally reported via #11787 / scala/scala#9999. But unfortunately that fix did not help in typelevel/cats#4244. It seems that adding the typeclass constraint breaks it.

[som-snytt]

The implicit section is skipped in the relevant code and the previous fix is also skipped. I will PR.

It occurs to me that we shouldn't ask for minimal reproducers but minimal use cases.

[SethTisue]

It occurs to me that we shouldn't ask for minimal reproducers but minimal use cases

Dale and I often note this — that one always wants an absolutely minimal version, but it's also often good to have something a bit more full that illustrates programmer intent and demonstrates how the issue might arise in practice