[kernel] Kernel AST invariants of `Library.dependencies`

[mkustermann]

Currently we're in a state where the Library.dependencies are often inaccurate at some point in a compilation pipeline:

• Missing imports: The body may (e.g. due to modular transformation inserting StaticInvocation ) use a member/type/... from another library without having an import in the library.dependencies

• Too many imports: The Library.dependencies may contain imports that aren't used (no member/type/.../reference of the import is used). See also [tfa] After TFA a library.dependencies may contain many dependencies that are unused #62111

So there's the question what Library.dependencies mean.

• What was written in the source code (and e.g. used for error reporting): If so, then it doesn't make all to much sense for transformations to change the dependencies (e.g. adding a dependency would be weird because it's not in the original sources). That in return means that the dependencies can't be relied upon to know what the library code actually references (though one can compute this information by traversing the library AST and collecting all member/type/.../reference uses from other libraries). That in return means we should just drop the dependencies after all diagnostics were emitted (and have the deferred loading AST expression nodes be a bit different).

• What the library body references: Then we should have an invariant that can be checked that there's no uses of a library without a corresponding import statement. It may also be good to have an invariant that we don't have unused imports. Furthermore we should ideally have uses annotated with the import they use (e.g. if we import library X twice, once normally and once via deferred import and we issue a call to a method we'd want to distinguish StaticInvocation(target) from DeferredStaticInvocation(target) and ConstantExpression from DeferredConstantExpression - see also [cfe] Knowledge of whether a ConstantExpression(<constant>) is from a deferred library or not #61764)

There's also interesting aspect about exports: If we want Library.dependencies to be precise, i.e. import iff there's a use, then instead of importing library X that re-exports Y, we should import Y instead and not X.

[johnniwinther]

cc @chloestefantsova @jensjoha