Implicit coercion of `Type` to `Identifier` doesn't work about sdk

[scheglov]

What make me worry is using TypeAnnotationArgument for something that might be not a type. If it is just an opaque identifier, then it would be clean to use such kind of Argument. OTOH, if it is definitely a named type like List<int>, we should use TypeAnnotationArgument.

What to do if (after the types phase) it turned out to be a type literal, is an open question. AFAIK in the analyzer we don't rewrite final x = int; from SimpleIdentifier to TypeLiteral(SimpleIdentifier), but that does not mean that this is a good example to follow :-)

@goderbauer Yes, currently the analyzer complains about any use of an identifier as an argument. We are trying to decide what should be done with such identifiers.

[jakemac53]

cc @scheglov @johnniwinther this feature would be nice for the stateful widget case (or in general when you want to generate a new class, and run macros on it which want to introspect on the original class).

It would be nice to prioritize it somewhat highly (but behind anything json macro related), to unblock experiments in this area for flutter.

[scheglov]

What kind of Argument should it be?

[jakemac53]

Oh, I thought we supported just Identifier, but it looks like not (and they aren't in the spec either).

For this case, a TypeAnnotationArgument would work too though. @goderbauer can you try that, using NamedTypeAnnotation as the field type?

Or, you could just do ExpressionCode, and then assert that you are given an expression with exactly one identifier (var identifier = code.parts.single as Identifier;, maybe with some error handling). But, the type annotation is probably better.

[scheglov]

Well, the specification says:

Here the macro takes an Identifier argument, and introspects on it to know how to generate the desired serialization and deserialization classes.

[scheglov]

There is a complication with identifiers. At least in the analyzer. This is related to the moment when we instantiate macros. We do this right after parsing a file, so all we have is unresolved AST. And without types built and resolved, we don't know if Foo in @MyMacro(Foo) is a type literal, or a function name.

We could disposeMacro() after the types phase, and re-instantiate with different arguments. Is this what you would expect?

Note, that people asked to arguments that are references to functions as well.

[jakemac53]

The macro does not see any details of the Identifier, so what I would do is create an opaque Identifier, which gets its true information filled in after the types phase?

Technically though, it is possible that a regular declaration could be added in the declarations phase, which shadows the identifier for the type....

[jakemac53]

And of course, it also isn't clear what the identifier should look like in the augmentation code from the first phase (what should the compiler say when asked to resolve the identifier to a URI by the augmentation library code?)

[goderbauer]

For this case, a TypeAnnotationArgument would work too though. @goderbauer can you try that, using NamedTypeAnnotation as the field type?

I tried both NamedTypeAnnotation and ExpressionCode as the type for the field in the macro without changing anything at the instantiation side (still @Foo(String)). I continue to get the same error.