Regression in `augustnagro/magnum` for implicit search

[WojciechMazur]

Based on OpenCB failure found in augustnagro/magnum - build logs

Compiler version

Last good release: 3.4.2-RC1-bin-20240311-02c2a6e-NIGHTLY
First bad release: 3.4.2-RC1-bin-20240312-3694d95-NIGHTLY
Bisect points to b28d4c1

Minimized code

class Repo[EC, E](using defaults: RepoDefaults[EC, E])
trait RepoDefaults[EC, E]
object RepoDefaults:
  inline given genImmutableRepo[E: DbCodec]: RepoDefaults[E, E] = ???
  inline given genRepo[EC: DbCodec, E: DbCodec]: RepoDefaults[EC, E] = ???

trait DbCodec[E]

case class PersonCreator(name: String)
case class Person(id: Long)
given DbCodec[Person] = ???
given DbCodec[PersonCreator] = ???

@main def Test = 
  val personRepo = Repo[PersonCreator, Person]

Output

[error] ./sandbox.scala:15:47
[error] No best given instance of type RepoDefaults[PersonCreator, Person] was found for parameter defaults of constructor Repo in class Repo.
[error] I found:
[error] 
[error]     RepoDefaults.genImmutableRepo[E](
[error]       /* ambiguous: both given instance given_DbCodec_Person and given instance given_DbCodec_PersonCreator match type DbCodec[E] */
[error]         summon[DbCodec[E]]
[error]     )
[error] 
[error] But both given instance given_DbCodec_Person and given instance given_DbCodec_PersonCreator match type DbCodec[E].
[error]   val personRepo = Repo[PersonCreator, Person]
[error]                                               ^
Error compiling project (Scala 3.5.0-RC1-bin-20240502-05354ba-NIGHTLY, JVM (17))

Expectation

Should compile

[odersky]

So we have this regression when #19922 is enabled and some other regressions that #19922 fixed. There is no way to address both sets of regressions at the same time, since each depend on a particular detail of the inference being enabled or disabled, respectively.

So what do we do? Some possible criteria to decide:

• Align with LTS, which means Revert broken changes with transparent inline #19922 should be reverted
• Minimize the breakages. It looks like Revert broken changes with transparent inline #19922 fixed two regressions and there is one new one? So that would suggest we keep the code as is.
• Do what's logical. The logic that Revert broken changes with transparent inline #19922 disabled does make sense, since result types of non-transparent inlines are not really different from result types of normal methods. So that again suggests we should revert Revert broken changes with transparent inline #19922.

So overall I think reverting #19922 is the right thing to do.

[odersky]

In fact I am not sure what LTS does?

[odersky]

One other argument for reverting #19922: Without #19922, if type inference breaks we can heal this by making the inline method in question transparent. With #19922, if type inference breaks the other way, there is no easy solution.