Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggressive codesig invalidation to trivial change in kotlinmodule/package.scala #4137

Open
lihaoyi opened this issue Dec 15, 2024 · 3 comments

Comments

@lihaoyi
Copy link
Member

lihaoyi commented Dec 15, 2024

Seems that any change in kotlinlib.package_#<init> transitively invalidates scala.PartialFunction and scala.collection.immutable.Seq, which ends up invalidating everything that calls Seq, which is basically everything

@ 
shortestPath("def build_.testrunner.package_$entrypoint$.$deserializeLambda$(java.lang.invoke.SerializedLambda)java.lang.Object", "def build_.kotlinlib.package_#<init>()void", res0) 
res3: Seq[String] = List(
  "def build_.testrunner.package_$entrypoint$.$deserializeLambda$(java.lang.invoke.SerializedLambda)java.lang.Object",
  "call build_.testrunner.package_$entrypoint$.$anonfun$ivyDeps$1(build_.testrunner.package_$entrypoint$)mill.define.TargetImpl",
  "def build_.testrunner.package_$entrypoint$.$anonfun$ivyDeps$1(build_.testrunner.package_$entrypoint$)mill.define.TargetImpl",
  "call mill.define.Target$#traverseCtx(scala.collection.immutable.Seq,scala.Function2)mill.define.Task",
  "external scala.collection.immutable.Seq",
  "external scala.collection.Seq",
  "external scala.PartialFunction",
  "def build_.docs.package_$site$$anonfun$moduleDeps$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
  "call build_.docs.package_$site$$anonfun$moduleDeps$1#applyOrElse(mill.define.Module,scala.Function1)java.lang.Object",
  "def build_.docs.package_$site$$anonfun$moduleDeps$1#applyOrElse(mill.define.Module,scala.Function1)java.lang.Object",
  "call build_.package_$#kotlinlib()build_.kotlinlib.package_$",
  "def build_.package_$#kotlinlib()build_.kotlinlib.package_$",
  "call build_.package_$!kotlinlib$lzycompute()build_.kotlinlib.package_$",
  "def build_.package_$#kotlinlib$lzycompute()build_.kotlinlib.package_$",
  "call build_.kotlinlib.package_$.<clinit>()void",
  "def build_.kotlinlib.package_$.<clinit>()void",
  "call build_.kotlinlib.package_$!<init>()void",
  "def build_.kotlinlib.package_$#<init>()void",
  "call build_.kotlinlib.package_!<init>()void",
  "def build_.kotlinlib.package_#<init>()void"
)

Basically anyone who calls any std lib API could potentially call some PartialFunction internally, and anyone who calls PartialFunction could call any implementation of PartialFunction, of which there are many auto-generate that end up calling all sorts of code in the build codebase. In the case above, we see the implementation of PartialFunction in
def build_.docs.package_$site$$anonfun$moduleDeps$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object (the collect block in build.docs.site.moduleDefs) ends up depending on build.kotlinlib in the second case block's if guard, which then adds a dependency on kotlinlib.package_#<init>

@lihaoyi
Copy link
Member Author

lihaoyi commented Dec 15, 2024

Here we can see in prettyCallGraph.json, scala.PartialFunction ends up potentially calling out to all sorts of anonymous implementations

{
    "external scala.PartialFunction": [
        "def build_.main.codesig.package_$CodeSigTests$$anonfun$$nestedInanonfun$caseKeys$1$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.docs.package_$site$$anonfun$moduleDeps$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.contrib.package_$$anonfun$contribModules$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.example.package_$$anonfun$exampleModules$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.docs.package_$$anonfun$$nestedInanonfun$brokenLocalLinks$7$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.dist.package_$$anonfun$allPublishModules$lzycompute$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.main.package_$$anonfun$$nestedInanonfun$buildInfoMembers$1$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "def build_.docs.package_$$anonfun$$nestedInanonfun$brokenRemoteLinks$8$1#applyOrElse(java.lang.Object,scala.Function1)java.lang.Object",
        "external java.lang.Object",
        "external scala.Function1"
    ]
}

@lihaoyi
Copy link
Member Author

lihaoyi commented Dec 15, 2024

Seems like we might need to tweak the heuristics to treat PartialFunction similar to SAM interfaces in the codesig analyzer

@lihaoyi
Copy link
Member Author

lihaoyi commented Dec 15, 2024

Not really a bug, as it's an expected outcome of the current codesig algorithm and heuristics, but we can probably improve upon it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant