Record Typedef reference into Kernel FunctionType and resynthesyze typedefs in Analyzer.

pkg/kernel/lib/ast.dart

 // Copyright (c) 2016, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 /// -----------------------------------------------------------------------
 ///                           ERROR HANDLING
 /// -----------------------------------------------------------------------
 ///
 /// As a rule of thumb, errors that can be detected statically are handled by
 /// the frontend, typically by translating the erroneous code into a 'throw' or
@@ skipping 4125 matching lines @@
   final List<TypeParameter> typeParameters;
   final int requiredParameterCount;
   final List<DartType> positionalParameters;
   final List<NamedType> namedParameters; // Must be sorted.
 
   /// The optional names of [positionalParameters], not `null`, but might be
   /// empty if information is not available.
   @informative
   final List<String> positionalParameterNames;
 
+  /// The [Typedef] this function type is created for.
+  @informative

[Paul Berry, 2017/08/03 20:25:45]

I think we should drop "@informative" here.

I realize this is a bit inconsistent with what I've said previously (that
"@informative" should be used for stuff that doesn't affect semantics), however
in this case it may be worth making an exception. 
 Consider the code:

a.dart:
  typedef void F(int i);
  F f;

b.dart:
  typedef void G(String s);
  main() {
    G g = f;
  }

When compiling b.dart, it would be nice if we could issue an error message "type
F can't be assigned to type G" instead of "type (int) -> void can't be assigned
to type (String) -> void".  To do that, we need the typedef references for both
types.  Since the type of f comes from a.dart, which might be resynthesized from
a summary, that means that we need the typedefReference to be preserved in the
summary.

So even though it's not technically semantically relevant, I think it's worth
dropping "@informative" for the benefit of good error messages.

(Note that dropping "@informative" carries a cost--it means that if someone
changes which typedef they're referencing, but the resolved type is the same,
then that will force a recompile which is technically unnecessary.  I think
that's going to be a rare enough occurrence that it's a worthwhile price to pay
for the opportunity to give better error messages)

[scheglov, 2017/08/03 21:00:32]

Done.

+  Reference typedefReference;
+
   final DartType returnType;
   int _hashCode;
 
   FunctionType(List<DartType> positionalParameters, this.returnType,
       {this.namedParameters: const <NamedType>[],
       this.typeParameters: const <TypeParameter>[],
       int requiredParameterCount,
-      this.positionalParameterNames: const <String>[]})
+      this.positionalParameterNames: const <String>[],
+      this.typedefReference})
       : this.positionalParameters = positionalParameters,
         this.requiredParameterCount =
             requiredParameterCount ?? positionalParameters.length;
 
+  /// The [Typedef] this function type is created for.
+  @informative

[Paul Berry, 2017/08/03 20:25:45]

Also drop "@informative" here

[scheglov, 2017/08/03 21:00:32]

Done.

+  Typedef get typedef => typedefReference?.asTypedef;
+
   accept(DartTypeVisitor v) => v.visitFunctionType(this);
 
   visitChildren(Visitor v) {
     visitList(typeParameters, v);
     visitList(positionalParameters, v);
     visitList(namedParameters, v);
     returnType.accept(v);
   }
 
   bool operator ==(Object other) {
@@ skipping 565 matching lines @@
   if (typedef_.canonicalName == null) {
     throw '$typedef_ has no canonical name';
   }
   return typedef_.canonicalName;
 }
 
 /// Annotation describing information which is not part of Dart semantics; in
 /// other words, if this information (or any information it refers to) changes,
 /// static analysis and runtime behavior of the library are unaffected.
 const informative = null;