Fasta does not produce annotations for typedef parameters

[scheglov]

const app = 0;
typedef int F(@app int app);

Analyzer needs to know resolution for @app at int app in F.
Oh, the this also tests the scope for @app is the library scope, not including the parameters scope.

[chloestefantsova]

Do I understand it correctly about the mentioned scopes, that @app resolves to the top-level field app, and not the parameter app? Can we just rename the parameter or the top-level field in the example above for clarity?

[bwilkerson]

That would appear to defeat the purpose of the test code. The whole point, as I understand it, is that there are two possible choices for how to resolve the reference in the annotation and fasta is currently making the wrong choice. If we renamed either declaration, then there would be no choice and the correct behavior would not be tested.

[chloestefantsova]

Thanks for the clarification, Brian. Now I understand that we're dealing with two issues here:

1. The annotation on formal parameters in function type aliases are discarded by the CFE, but should present in the compiler output. I've just checked that it's indeed the case, and we need to solve it. I think I know how to fix it.

2. There is a concern that the future fix for issue 1 described above will make the wrong choice when resolving app in @app, and we may use the example above to verify the behavior of the compiler.

[eernstg]

For 2., I believe the parameter app should be ignored when app in @app is looked up. We have the following in line 991 (section 'Formal Parameters') of dartLangSpec.tex, 2efe344:

Every formal parameter introduces a local variable into the formal parameter scope.
The current scope for the function's signature is the scope that encloses
the formal parameter scope.

This means that a parameter name is not in scope in the function's signature. Unfortunately, there is no information (section 19.3.1 'Typedef') about scoping for old style type aliases, but I would certainly find it natural to clarify that issue in a way that confirms that the parameter names are not in scope in the signature, also when it occurs in a type alias. This means that those names are never in scope anywhere at all, and that's also the way it should be.

[chloestefantsova]

A possible fix could be found in CL 65701.

[scheglov]

I remember seeing somewhere that we are going to forbid annotations in typedefs, and generic functions. is this true? @eernstg

Are we going to ban them also on nested parameters of function typed formal parameters?

const a = 0;
main(p1(@a p2)) {}

Currently CFE does not report them.

This also causes crash in Analyzer integration, because AstBuilder parses them, but BodyBuilder does not resolve. I guess we need to make our mind, and either don't parse, and report an error; or resolve them.

[eernstg]

We should definitely have a well-defined response for this kind of metadata, but we don't currently have a very clear delineation of the required level of support.

With a functionType, that is, the int Function<X>(List<X>) style types that we introduced in order to get support for generic function types, there is no syntactic support for metadata on parameter types, so that's simply a syntax error.

With the old style functionFormalParameter, that is, the type of f in void foo(int f(List<dynamic> xs)), the formal parameters use the same syntax as that of an actual function declaration. This means that metadata is allowed by the grammar, and checking with dartanalyzer and dart I get successful runs with the following:

const a = 42;

main() {
  int bar(void f(@a int i)) => 42;
  bar(null);
}

Considering that a function type is a composite entity, I don't see anything inherently wrong with having support for putting metadata on specific parts of it, but we'd need to decide that this is what we do, and then we'd need to adjust the functionType syntax to allow it. We'd also need to decide on how to determine whether a given metadatum applies to a function type as a whole or only to its return type when it occurs at first (@a void Function(int)), so we would need to think about it a little bit before everything is in place.

I also seem to remember that this feature does not have unconditional support, but I can't find it in any documents at this point, so I'll leave it to anyone who is worried to say why.