Support for NamedExpression(s) as constructor initializer arguments.

pkg/analyzer/lib/src/summary/idl.dart

 // Copyright (c) 2015, 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.
 
 /**
  * This file is an "idl" style description of the summary format.  It
  * contains abstract classes which declare the interface for reading data from
  * summaries.  It is parsed and transformed into code that implements the
  * summary format.
  *
@@ skipping 1016 matching lines @@
   List<int> get ints;
 
   /**
    * Indicates whether the expression is a valid potentially constant
    * expression.
    */
   @Id(5)
   bool get isValidConst;
 
   /**
+   * If the expression is a [NamedExpression], the name of the expression.
+   */
+  @Id(7)
+  String get name;

[Paul Berry, 2016/05/05 21:47:02]

It seems like an unfortunate inconsistency that we only use this mechanism for
named arguments to "super." and "this." constructor initializers, and for all
other kinds of named arguments, the expressions are serialized without reference
to their name, and the names are stored somewhere associated with the call site.
 (For example, with UnlinkedConstOperation.invokeConstructor, the names are
stored in UnlinkedConst.strings before the expressions for the constant values).

How about if, instead of storing the names here, we add an "argumentNames" field
(of type List<String>) to UnlinkedConstructorInitializer?

So for example, when serializing `class C { C() : super(0, x: 1, y: 2); }`,
UnlinkedConstructorInitializer.argumentNames would be `['x', 'y']`.

[scheglov, 2016/05/05 21:56:58]

Well, I actually started to implement it this way. But this makes implementation
more complex and less clear than adding "name" to UnlinkedConst. Instead of just
consistently serializing any Expression we would need to support two parallel
data structures - for simple expressions and optional names.

I see benefits of storing in-expression named arguments in "strings", but in
this case IMHO we can use simpler approach.

[Paul Berry, 2016/05/05 22:04:28]

Hmm, It's not clear to me where the additional source of complexity comes in.

Since this is blocking the DDC team, let's land it as is.  I'll try to find time
to experiment with the alternative implementation and see if it becomes clear to
me why it's more complex.

+
+  /**
    * Sequence of operations to execute (starting with an empty stack) to form
    * the constant value.
    */
   @Id(0)
   List<UnlinkedConstOperation> get operations;
 
   /**
    * Sequence of language constructs consumed by the operations
    * `pushReference`, `invokeConstructor`, `makeList`, and `makeMap`.  Note
    * that in the case of `pushReference` (and sometimes `invokeConstructor` the
@@ skipping 1650 matching lines @@
    */
   @Id(11)
   int get visibleLength;
 
   /**
    * If a local variable, the beginning of the visible range; zero otherwise.
    */
   @Id(12)
   int get visibleOffset;
 }