Over-compilation with a generic type used as a member parameter type

[OndrejSpanel]

Follow-up to #1396

steps

• checkout https://github.com/OndrejSpanel/ZincOvercompile
• if using IntelliJ IDE, make sure you have highlighting set to Built-in, not Compiler
• from sbt use clean;compile
• change the local variable name in Entities.f or change the comment in the same file
• use compile

problem

Both files are compiled:

[info] compiling 2 Scala sources to C:\Dev\ZincOvercompile\target\scala-2.13\classes ...

expectation

On a change which does not change the API, no other source files than the one edited should be compiled.

notes

• I have developed a SBT plugin to help me isolating problems like this. It checks sbt.internal.inc.Analysis and prints which files were compiled and what classed have changed their API as a result of compilation. When using this plugin on this repro, it does not show any API changes.
• In a real project much more files are compiled than just 2, often in multiple compilation cycles
• The same repro works with Scala 3 and 2

The repro is surprisingly simple:

Entities.scala:

object Entities {

  // change comment HERE to trigger compilation of both files
  // or rename the local variable below

  def f(): Unit = {
    val add142 = 0
  }
}

class Entities {
  def get(id: EntityId[EntityState]): Option[Int] = ???
}

State.scala:

class EntityId[T]

trait EntityState {
  def parentEntity(entities: Entities): Option[Int] = None.flatMap(entities.get)
}

[Friendseeker]

c.c #598

This behaviour is intentional. State.scala refers to Entities.scala and vice versa, hence using strategy proposed in #598 (comment) both files are invalidated in the first cycle.

[OndrejSpanel]

Oh my. 😞Back to the repro of the original issue of over-compilation of 100 files, which will be something different. With the plugin ready it should hopefully not take a whole day this time. 😶