Generated names of context bound parameters change on incremental compilation causing unnecessary invalidations

[mrdziuban]

Compiler version

3.3.0, also happens with 3.3.1-RC1

Minimized code

Unfortunately I haven't been able to come up with a minimal reproduction. This happens in a large, private codebase, and my attempts to replicate the behavior have so far been unsuccessful.

For what it's worth, this is a simplified version of what the code looks like (note that this doesn't reproduce the issue):

object myObject {
  sealed trait Thing {
    def call(): Option[String]
  }
  case class Thing1(o: Option[String]) extends Thing {
    def call(): Option[String] = o.map(s => s"Thing1($s)")
  }

  case class MyType[A](a: A)

  object MyType {
    implicit def myTypeClass[A: MyTypeClass]: MyTypeClass[MyType[A]] = MyTypeClass.derived
  }
}

If I change the string in Thing1.call from "Thing1($s)" to "Thing($s)" (or anything else that doesn't change the signature of Thing1.call) then recompile, I see that the context bound on MyType.myTypeClass has been renamed, causing invalidation of anything that depends on MyType.

Output

I've enabled debug output in sbt with the following settings:

ThisBuild / logLevel := Level.Debug
ThisBuild / incOptions ~= (_.withApiDebug(true).withRelationsDebug(true))

And I see a number of diffs to the API that look like this (shown as a git diff for syntax highlighting):

- [diff] implicit def myTypeClass[ A >: scala.this#Nothing <: scala.this#Any](implicit evidence$63: example.this#MyTypeClass[<A>]): example.this#MyTypeClass[example.myObject$.this#MyType[<A>]]
+ [diff] implicit def myTypeClass[ A >: scala.this#Nothing <: scala.this#Any](implicit evidence$81: example.this#MyTypeClass[<A>]): example.this#MyTypeClass[example.myObject$.this#MyType[<A>]]

Note that the only thing changed is the name of the MyTypeClass parameter, from evidence$63 to evidence$81.

Expectation

Context bound parameter names shouldn't change, or at least they shouldn't cause API invalidation.

[eed3si9n]

@mrdziuban (Not that I maintain Dotty compiler bridge, but ) Thanks for reporting this!

[eed3si9n]

Likely relevant code:
https://github.com/lampepfl/dotty/blob/484be60846be17acee74cfe1c6ea16c10894303f/compiler/src/dotty/tools/dotc/sbt/ExtractAPI.scala#L392-L397

[odersky]

There are two ways we might want to fix this:

• Ignore generated names when extracting the API, or rather, map them all to the same placeholder name
• Make fresh name generation more predictable by having smaller scopes in which fresh names must be unique (right now, it's the compilation unit).

Maybe do both?

[mrdziuban]

Update on my end -- I've been progressively deleting code from my codebase until the issue goes away and it finally has!

There's one specific file that imports types like myObject.MyType in order to define typeclass instances for them. If I delete that file, or I refactor the code to define the typeclass instance in the MyType companion object instead, then the issue disappears.

This doesn't fix the issue in my full codebase, however, so there must be other contributing factors. Just wanted to share the update in case it helps debug what's going on.

For example in code:

Before -- issue exists

// file that contains myObject
object myObject { /* code as above */ }

// culprit file
import myObject.MyType

object otherObject {
  trait AnotherTypeClass[A]

  object AnotherTypeClass {
    implicit def myTypeInst[A]: AnotherTypeClass[MyType[A]] = ...
  }
}

After -- issue does not exist

// file that contains myObject
import otherObject.AnotherTypeClass

object myObject {
  // ...
  object MyType {
    implicit def myTypeInst[A]: AnotherTypeClass[MyType[A]] = ...
  }
}

// culprit file
object otherObject {
  trait AnotherTypeClass[A]
}

[eed3si9n]

@mrdziuban I can't seem to reproduce this issue. Could you put a set of complete code that can reproduces this somewhere public please?

[mrdziuban]

@eed3si9n still working on it, I'll post back here if/when I can do so.

[mrdziuban]

@eed3si9n I've minimized it as far as I can, down to only 3 files and less than 60 lines of code. Code and instructions for reproducing are in https://github.com/mrdziuban/dotty-issue-18080. Both methods in Queries.scala with context bounds (database.queries$.ResultSet.getV and database.queries$.ClientOwnerId$.parseClientOwnerId) show that the names change -- there's a screenshot in the README showing the debug output

[mrdziuban]

Also just added a script to that repo that may come in handy when testing fixes. Just running ./test.sh will confirm whether the issue is still reproducible and will show output like this

[eed3si9n]

@mrdziuban Thanks!