Cannot access Annotation from ElementAnnotation

[blois]

We have a number of code gen scenarios where we need to access the parameters passed to the annotation, it's currently a pain to do this when dealing with elements (have to get the index of the annotation, go up to the element, get the node, then get the annotation by that index).

Would be great if the Annotation AST node was exposed from ElementAnnotation.

[clayberg]

Set owner to @bwilkerson.
Added this to the 1.3 milestone.
Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Medium labels.

[blois]

In addition, would be nice if Annotation.element went back to ElementAnnotation.

[bwilkerson]

We have a number of code gen scenarios where we need to access the parameters passed to the
annotation, it's currently a pain to do this when dealing with elements (have to get the index of
the annotation, go up to the element, get the node, then get the annotation by that index).

Would be great if the Annotation AST node was exposed from ElementAnnotation.

I agree. Unfortunately, there are some technical challenges with providing that support. If you have ideas on how to address these challenges I'd love to hear them.

In order to be able to better manage the amount of memory being used by analyzer we decided to discard the AST structures when we no longer needed them. One requirement to allow this is that the element model (which is longer lived) cannot have any reference back to the AST nodes.

And while there is currently a method in Element (getNode()) that violates that principle, it has three problems. First, it can be expensive because if the AST has been discarded it will have to be re-created, which means re-reading and parsing the file. Second, it only works when you're accessing the element model through a context. And third, and perhaps most importantly, because of the first problem we can't support this operation in a world in which only async IO is allowed (which means it either needs to go away or be converted to return a future.

In addition, would be nice if Annotation.element went back to ElementAnnotation.

Makes sense, but ElementAnnotation isn't an Element. We could, however, provide a different accessor that would return the ElementAnnotation. I assume that would work as well.

[blois]

We're creating a lot of transformers which are metadata driven, most of these are either operating against a resolved AST or are moving in that direction (otherwise it's a fancy string search).

It really seems like proper processing of metadata requires a mix of elements and AST- removing Element.getNode would break a lot of code.

[bwilkerson]

It really seems like proper processing of metadata requires a mix of elements and AST ...

That's not surprising. It might be easier if we actually computed the values of the annotations so that you could interact with the objects (or mirrors of them), but we've been reluctant to implement even the subset of execution semantics needed for constants.

Is there additional information we could attach to the Element model to negate the need to get back to the AST?

... removing Element.getNode would break a lot of code.

We can leave the API if we modify it to return a Future. Not sure whether that will be good enough. I expect that many of the methods in AnalysisContext will also need to either return a Future or be removed.

Would it work for you to traverse the resolved AST's rather than the elements (after we've resolved Annotations to ElementAnnotations)?

[blois]

This is effectively what we are doing already. If you look at Angular,
Polymer or DI- all of them make heavy use of annotation parameters. But
they limit the syntax supported.

The arguments to the annotation constructor.

We've had a lot of issues with async-only APIs, I'd strongly recommend
providing a synchronous version of the APIs as well. It's probably a larger
discussion to be had elsewhere, but lets discuss if you're considering
removing sync APIs.

This would probably work- I do this in a couple of places since it's so
difficult to go the other way.

[bwilkerson]

Access from an Annotation to the ElementAnnotation is provided in https://codereview.chromium.org/193833003/ (bleeding edge revision 33532).

It's probably a larger discussion to be had elsewhere, but lets discuss if you're
considering removing sync APIs.

A discussion might be good. I'm guessing, though, that the best way to do that would be to have both sync and async versions of each method (named "foo" and "fooSync") where the synchronous version can throw an exception if it requires synchronous IO in an environment where synchronous IO isn't allowed.

[clayberg]

Removed this from the 1.3 milestone.
Added this to the 1.4 milestone.

[kasperl]

Removed this from the 1.4 milestone.
Added this to the 1.5 milestone.

[bwilkerson]

Removed this from the 1.5 milestone.
Added this to the Later milestone.

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[sigurdm]

That's not surprising. It might be easier if we actually computed the values of the annotations so that you could interact
with the objects (or mirrors of them), but we've been reluctant to implement even the subset of execution semantics needed for constants.

In dart2js-land we concluded that we need two views on constants: ConstantExpression and ConstantValue.
The ConstantExpression tells how the constant is constructed (variables, fields, constructors (with a mapping arg -> value), operations on constants etc.)

ConstantValues (the evaluation of an expression in a constant environment) are primitives lists, maps or
constructed constants (with a mapping field->value).

I think for the purpose of making language tools (transformers etc.) with the analyzer package a similar representation would be very beneficial.

For example for the reflectable package we want to be able to recognize any annotation of the "value" of a given class (similar to the problem in issue #15467).

Also we want to be able to insert the default value from some function-argument into some code - here we need the expression to be able to generate code that creates the same constant.

[sigurdm]

Are there any updates on this?

[bwilkerson]

I'm closing this as stale. Please re-open if this is still an issue.