Interaction between path-dependent types and default args fails to compile

[jbwheatley]

Compiler version

3.7.0-3.7.3, 3.8.0-RC1-bin-20250819-1f13619-NIGHTLY

(Compiles on 3.6.4)

Minimized code

trait Typeclass[I]

sealed trait Enumm {
  type Insider
}

object Enumm {
  case object Enumm1 extends Enumm {
    case class Insider()

    object Insider {
      given t: Typeclass[Insider] = new Typeclass[Insider] {}
    }
  }
}

class Foo
implicit val f: Foo = new Foo

def pathDependentTypeDefaultParam(tpe: Enumm)(i: tpe.Insider, p: Int = 0)(using t: Typeclass[tpe.Insider]): Int = p
def defaultParamNotPDT(tpe: Enumm)(i: tpe.Insider, p: Int = 0)(using t:Foo): Int = p
def pathDependentTypeDefaultParamOwnList(tpe: Enumm)(i: tpe.Insider)(p: Int = 0)(using t: Typeclass[tpe.Insider]): Int = p

def main = {
  //doesn't compile
  //Error: No given instance of type Nothing & Typeclass[? <: Enumm.Enumm1#Insider] was found for parameter t of method foo
  pathDependentTypeDefaultParam(Enumm.Enumm1)(Enumm.Enumm1.Insider())

  //compiles if default arg given explicitly
  pathDependentTypeDefaultParam(Enumm.Enumm1)(Enumm.Enumm1.Insider(), p = 0)

  //compiles if using non-path-dependent given
  defaultParamNotPDT(Enumm.Enumm1)(Enumm.Enumm1.Insider())

  //with default args in own parameter list again doesn't compile
  //Error: No given instance of type Nothing & Typeclass[? <: Enumm.Enumm1#Insider] was found for parameter t of method foo3
  pathDependentTypeDefaultParamOwnList(Enumm.Enumm1)(Enumm.Enumm1.Insider())()

  //again, compiles if default arg given explicitly
  pathDependentTypeDefaultParamOwnList(Enumm.Enumm1)(Enumm.Enumm1.Insider())(p = 0)
}

Output

[error] -- [E172] Type Error: /Users/jackwheatley/work/37test/src/main/scala/main.scala:29:69 
[error] 29 |  pathDependentTypeDefaultParam(Enumm.Enumm1)(Enumm.Enumm1.Insider())
[error]    |                                                                     ^
[error]    |No given instance of type Nothing & Typeclass[? <: Enumm.Enumm1#Insider] was found for parameter t of method pathDependentTypeDefaultParam
[error] -- [E172] Type Error: /Users/jackwheatley/work/37test/src/main/scala/main.scala:39:78 
[error] 39 |  pathDependentTypeDefaultParamOwnList(Enumm.Enumm1)(Enumm.Enumm1.Insider())()
[error]    |                                                                              ^
[error]    |No given instance of type Nothing & Typeclass[? <: Enumm.Enumm1#Insider] was found for parameter t of method pathDependentTypeDefaultParamOwnList
[error] two errors found

Expectation

The above code compiles in 3.6.4. Default arguments shouldn't affect implicit resolution.

[jdrphillips]

The same bug was present in 2.13 but less severe

[Gedochao]

Last good release: 3.7.0-RC1-bin-20250309-2f639e2-NIGHTLY
First bad release: 3.7.0-RC1-bin-20250312-3fe9304-NIGHTLY
c37dc8b is the first bad commit (#22458)
cc @som-snytt

[som-snytt]

Note to self about how it worked at the last "good" commit:

The bug involves the type of the application when it is rewritten to a block by wrapDefs:

def f(x: X)(y: x.T, i: Int = 42)(using U): Z = ???

f(x)(x.y) --> { val tmp = x; f(tmp)(tmp.y, default_i(tmp)) } // (using U): Z but avoidingType makes it (using Nothing): Z

Normally, adaptNoArgs finds implicit args from the incoming method type, but (using Nothing) is not helpful.

What actually happens is that it tries to construct an Apply, notices that there are default parameters somewhere (albeit not in the current parameter list), which gives it hope, so it ships what it has off to typedApply via typed, which works by recovering the fun via methPart. Note simpleApply says "no implicits" but tryDefault used implicitArgTree in the previous commit.

With the "bad" commit, avoidingType assigns (using Nothing & Typeclass[? <: E.E1#Insider]) which presumably "fails" in the same way but doesn't recover by typing the "bad" application (I see the current code has a tighter condition in tryDefault for when to wield implicitArgTree).

There are a couple of approaches to the underlying problem (the unuseful type of the wrapping block). It would also be nice if the "protocol" between adaptNoArgs and typedApply were simpler and more uniform, perhaps also treating implicit arg lists the same for using kind.

As an ancillary issue, there is a question about the "order of precedence" of implicit params and their defaults. The change was at 55d7300 which elegantly explains that it's as if all the other params had a default arg of the form x: T = summon[T]. I think it is still unintuitive that "whether to use an available given or a default arg" is flipped for "explicit using" applications.