Should adding newlines inside a method invalidate dependent tasks?

[bherw]

I'm not sure if this is an issue or if this is even supported.

Tasks in general are invalidated if the code they depend on changes, at a method-level granularity via callgraph reachability analysis. See #2417 for more details

• https://mill-build.org/mill/depth/caching.html

This led me to believe that Mill can invalidate compilation tasks based on the actual changes to methods, so if I edit the content of a method or add some private methods/constants and don't change a class' ABI, then I would not expect the dependent modules to be rebuilt. Is that correct?

Testing this on my utilities library, it seems like Mill is actually able to determine that not all modules need to be rebuilt for a change to utilities. But it's very odd which modules mill actually chose to rebuild. The modules chosen were consistent, but didn't seem to make sense, as they weren't actually depending on the specific class that I edited. I had a moduleDep dependency graph of A -> B -> C, and also A -> C, but when making changes to a class in A that C uses but B does not, only B got rebuilt, and C was skipped, which seems strange.

I was testing this out with the javalib/basic/7-multi-module and it seems like most code changes inside the Bar class always cause the dependent module to recompile.

Causes foo to recompile:

• adding a newline before the return statement inside a method (e.g. Bar#generateHtml)
• adding a new unused method (etiher private or public)
• adding or removing newlines before a private method declaration (I guess this is changing the line number the method is declared on?)
• adding a new empty class to the bar module.

The only cases in which I found foo did not recompile:

• adding a newline after the last method
• adding a newline to the end of the file