[record_use] Semantics: link hooks caching with recorded uses

[dcharkes]

We'd like to only rerun link hooks when they need to be rerun, and resources.json* is an input to link hooks.

We can explore a few different options.

1. Always rerun when the resources.json changes (as implied by Define the resources.json format from @ResourceIdentifiers and @pragma('dart2js:resource-identifier') sdk#55494 (comment)). However, this would cause all link hooks to be rerun on any changes (minus source locations).
2. Have link output specify what in the resources.json is depended on. This would be analogous to the build and link output specifying what files on the file system are depended on.
3. Have the build hook belonging to the same package specify what will be depended on by the link hook of that package. This would be asymmetric from the file dependencies that are after the fact. (We don't require build and link hooks to output the dependencies, which is a list of files and directories up front. As that would prevent relying on the native toolchain to provide such list of files/dirs.) But, it would theoretically enable filtering the resources.json to only contain what was requested. (However, with that kind of logic we should also give the build and link hooks a FileSystem from package:file that only shows the paths existing that were requested up front to be used.)
4. Having @ResourceIdentifier* and it subtypes have a Set<String> packageLinkHook. And then filter the resources.json before invoking the link hook based on whether the annotation is destined for a package link hook. This approach is slightly less flexible than option 2 or 3 due to only the annotations being used. One cannot specify other types of dependencies. (And again it's slightly different from that we do give access to the full file system.) The last downside is that the author who owns the annotation class needs to know what linkers this annotation will be used in.

* To be renamed.

For option 2. The question is what kind of dependencies for inside the resources.json should one be able to specify? And how does one specify dependencies that would be depended on if they existed. E.g. For file system dependencies we have directories, and we have considered adding globs (#1101). Can we have something similar for parts of a resources.json? Some candidates:

• The annotation class and library URI the class is in. (Basically functionality of option 4.)
  • The library URI should probably be prefix or regex allowed, to enable the class being anywhere inside a package.
  • The annotation class should maybe also be prefix/regex allowed, to enable depending on all classes that subclass ResourceIdentifier.
• The definition (name, parent, and library uri). This is not strictly needed, users can just depend on the annotation used to annotate the definition. That annotation might be too broad, and lead to too granular caching, but I believe that to be unlikely.
• (Something related to whatever we add to the treeshaking information in the future. E.g. if start recording class hierarchies and left over constants, it's not clear yet whether all of what we record will have annotations.)

Maybe filtering on annotation class and library uri is enough?

Thanks for bringing it up @mkustermann! And thanks for a useful discussion @HosseinYousefi @mosuem @liamappelbe @mkustermann! I've tried to write down the options in this issue. Did I miss anything from our discussion? Any other things that pop to mind?

[mosuem]

I would prefer going with option 2 and keeping the filtering simple, for example specifying a list of annotations the linker depends on.

1 - Is a good choice for now, but will become an issue later when there are multiple long-running link hooks.
3 - Feels similar to 2., but more complicated.
4 - Feels like leaking implementation details from how we design link hook caching into the ResourceIdentifier annotation.