TargetKind for resource identifiers annotations

[mosuem]

Based on the comment on a CL.

We are introducing an annotation @ResourceIdentifier to record usage of methods and their arguments and annotations at compile time, to be used in a link hook for tree shaking assets. The targets of this annotation are for now:

• Static methods (including methods in extensions)
• Classes with a const constructor, to target annotations

Possible future targets might be

• Top level methods
• Instance methods

It is unclear if instance methods would be possible to track, as the use of dynamic prevents knowing if they are referenced at compile time.

Currently, the placement of the annotation is checked in pkg/front_end. Would it make sense to introduce a custom TargetKind, or a set of TargetKinds, to be placed on the annotation definition itself?

cc @bwilkerson

[bwilkerson]

Would it make sense to introduce a custom TargetKind, or a set of TargetKinds, to be placed on the annotation definition itself?

I think it would make sense. It's better for users if we can surface this kind of diagnostic in the IDE rather than waiting until running a compiler.

It sounds like you'd currently need to add a target kind for static methods within classes, enums, mixins, extensions and extension types. In the future you might need one instance methods, but that's unknown at the moment. I think everything else is already covered, with one minor caveat.

Classes with a const constructor ...

I don't think we want to use TargetKind for that kind of check. It makes sense to use TargetKind.classType, but the restriction that the class must have at least one const constructor is, IMO, outside of how we want to use TargetKind and would need additional validation in the analyzer. That isn't hard to do, just something to keep in mind.

It is unclear if instance methods would be possible to track, as the use of dynamic prevents knowing if they are referenced at compile time.

Yes, dynamic is an issue, but probably for a very small percentage of users. It might be reasonable to support instance methods with a caveat that they don't work for dynamic targets, but I also don't know how useful it would be for users to have the ability to annotate instance methods.

[lrhn]

Should we extend, or replace, the TargetKind annotation to be able to define more fine-grained predicates on declarations?
Say, being able to select only "static getters of classes" or "const constructors of extension types"?

[bwilkerson]

Maybe. I considered that initially, but was expecting (hoping?) that we wouldn't need that kind of complexity. The plan was to introduce subsets of categories when the finer granularity was needed. For example, if TargetKind.method is too broad, we could add TargetKind.staticMethod. It's possible that we are reaching a point where that isn't sufficient.

I'm reluctant to try to make a fully general mechanism because of the complexity that comes with that, including the need to produce diagnostics when an invalid combination of modifiers is used.