Add optional FunctionType.positionalParameterNames and use them to resynthesize function-type forma…

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 4073 matching lines @@
   accept(DartTypeVisitor v) => v.visitVectorType(this);
   visitChildren(Visitor v) {}
 }
 
 /// A possibly generic function type.
 class FunctionType extends DartType {
   final List<TypeParameter> typeParameters;
   final int requiredParameterCount;
   final List<DartType> positionalParameters;
   final List<NamedType> namedParameters; // Must be sorted.
+
+  /// The optional names of [positionalParameters], might be empty, but
+  /// not `null`.

[Siggi Cherem (dart-lang), 2017/07/31 17:43:08]

it might be a bit confusing if positionalParameters.length and
positionalParameterNames.length have different length (even if 0), is there a
reason why we can't use `null` as a default instead?

[scheglov, 2017/07/31 20:35:30]

In flatbuffers every type has default value. For lists default value is an empty
list. This makes life easier - we don't need separate flags to mark null values
- always just length and values.

+  @informative

[Siggi Cherem (dart-lang), 2017/07/31 17:43:07]

General question about what we should do about @informative fields: I know we
want to support having .dill files with and without this data (so we can exclude
it when it is not needed). What are your thoughts on how to exclude it:
 - compute it in fasta always, then omit it during serialization
 - make fasta smarter to optionally produce the data (e.g. use a compiler-option
to ensure they are built), then serialize in the same way regardless.

[scheglov, 2017/07/31 20:35:30]

Well, ultimately any computation, which results we don't use, is useless and
should be prevented.
So, I think we should stop computing these values where it is cheaper to skip
than to compute.

Nothing prevents us from doing this at any point in time.

+  final List<String> positionalParameterNames;
+
   final DartType returnType;
   int _hashCode;
 
   FunctionType(List<DartType> positionalParameters, this.returnType,
       {this.namedParameters: const <NamedType>[],
       this.typeParameters: const <TypeParameter>[],
-      int requiredParameterCount})
+      int requiredParameterCount,
+      this.positionalParameterNames: const <String>[]})
       : this.positionalParameters = positionalParameters,
         this.requiredParameterCount =
             requiredParameterCount ?? positionalParameters.length;
 
   accept(DartTypeVisitor v) => v.visitFunctionType(this);
 
   visitChildren(Visitor v) {
     visitList(typeParameters, v);
     visitList(positionalParameters, v);
     visitList(namedParameters, v);
@@ skipping 569 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;