Investigate why changing the body of a task or method causes downstream files to re-compile

[lihaoyi]

In the CodeSigSubfolderTests suite, we can see that modifying the body of task or helper method in the upstream subfolder/package.mill causes the downstream build.mill to recompile:

mill/integration/invalidation/codesig-subfolder/src/CodeSigSubfolderTests.scala

Lines 42 to 73 in 5f617f0

	modifyFile(
	workspacePath / "subfolder/package.mill",
	_.replace("running subFolderTask", "running subFolderTask2")
	)
	// Changing stuff in subfolder/package.mill does not invalidate unrelated tasks in build.mill
	val cached3 = eval("foo")
	assert(cached3.out == "")
	// TODO: why is this compiling both sources when we only changed
	// one file and did not change any public type signatures?
	assert(cached3.err.contains("compiling 2 Scala sources"))
	modifyFile(
	workspacePath / "subfolder/package.mill",
	_.replace("running helperFoo", "running helperFoo2")
	)
	val mangledHelperFoo = eval("foo")
	assert(mangledHelperFoo.out.linesIterator.toSeq == Seq("running foo2", "running helperFoo2"))
	// TODO: why is this compiling both sources when we only changed
	// one file and did not change any public type signatures?
	assert(mangledHelperFoo.err.contains("compiling 2 Scala sources"))
	// Make sure changing `val`s, which only affects the Module constructor and
	// not the Task method itself, causes invalidation
	modifyFile(
	workspacePath / "subfolder/package.mill",
	_.replace("val valueFoo = 0", "val valueFoo = 10")
	)
	val mangledValFoo = eval("foo")
	assert(mangledValFoo.out.linesIterator.toSeq == Seq("running foo2", "running helperFoo2"))
	// TODO: why is this compiling both sources when we only changed
	// one file and did not change any public type signatures?
	assert(mangledValFoo.err.contains("compiling 2 Scala sources"))

This is at odds with how incremental compilation is meant to work, and indeed when testing out simple two-file compilation modules standalone, changing the body of a method in an upstream file without changing the signature does not cause the downstream file to recompile

[lihaoyi]

Here's a minimal reproduction of the problem with Zinc 1.10.2 incremental compilation outside of Mill:

build.scala

package build

object outer {
  def foo = { build.subfolder.inner.helperFoo }
}

subfolder/package.scala

package build.subfolder
import build.{outer => unused}

class Unused

object inner  {
  def helperFoo = { 1 }
}

In Scala 2.13.15:

• With the import build.{outer => unused}, we see changes to subfolder/package.scala causing build.scala to be recompiled, even though the signatures in package.scala did not change

• If class Unused is removed, we see changes in build.scala causing subfolder/package.scala to be recompiled, even though it does not depend on build.scala

In Scala 3.5.0:

• With the import build.{outer => unused}, we see changes to either file causing both to re-compile, even if signatures did not change

• class Unused has no effect

[lihaoyi]

Seems like a regression in Zinc 1.10.x, starting 1.10.0-M1. Reverting to 1.9.6 seems to fix the problem (?)

[lihaoyi]

sbt/zinc#1461. Not sure if this is the only issue, but it seems to make the test introduced in #3750 behave appropriately