Zinc invalidation when nested inline method changes

[adpi2]

Compiler version

Latest nightly:

scalaVersion :=  "3.0.0-RC2-bin-20210320-0195dff-NIGHTLY"

Minimized code

// Show.scala
case class Show(name: String)
  
object Show:
  inline given Show = foo
  
  private inline def foo: Show = Show("foo")

// App.scala
@main def app() =
  println(summon[Show].name)

Output

1. compile and run

sbt:dotty-bug> run
[info] compiling 2 Scala sources to /home/piquerez/lampepfl/dotty-bug/target/scala-3.0.0-RC2/classes ...
[info] running app 
foo
[success] Total time: 0 s, completed Mar 23, 2021, 2:55:05 PM

2. change the implimation of the private inline foo method

 object Show:
   inline given Show = foo
   
-  private inline def foo: Show = Show("foo")
+  private inline def foo: Show = Show("bar")

3. compile and run again

sbt:dotty-bug> run
[info] compiling 1 Scala source to /home/piquerez/lampepfl/dotty-bug/target/scala-3.0.0-RC2/classes ...
[info] running app 
foo
[success] Total time: 0 s, completed Mar 23, 2021, 2:57:21 PM

The app.scala file is not invalidated and thus not recompiled.
The produced program should print "bar" instead of "foo".

Expectation

The app.scala file should be recompiled.

[adpi2]

Actually Show does not need to be resolved implicitly.

I have the same behavior with:

case class Show(name: String)
  
object Show:
  inline def foo: Show = bar
  inline def bar: Show = Show("foo")

@main def app() =
  println(Show.foo.name)

[smarter]

Currently, the API hash of an inline method contains a hash of the body of the method: https://github.com/lampepfl/dotty/blob/c0b3fde1dbe9a8ef3b87ddfaa873ea945beafa8c/compiler/src/dotty/tools/dotc/sbt/ExtractAPI.scala#L588-L682 I think we need to go further and also recursively include the bodies of inline methods called from this method, keeping in mind that this requires maintaining a set of seen methods to make sure we don't recurse infinitely. (This is a bit annoying since it means we need to traverse the same inline method multiple times every time we see it called from some other inline method, but any solution that tries to reuse hashes is bound to be very complicated because we can have mutually-recursive inline methods that can even be defined in separate compilation units)

[bishabosha]

so there is no issue with inlining being later now - we can still access the bodies