Support for NamedExpression(s) as constructor initializer arguments.

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

Index: pkg/analyzer/lib/src/summary/idl.dart
diff --git a/pkg/analyzer/lib/src/summary/idl.dart b/pkg/analyzer/lib/src/summary/idl.dart
index 0c3f379ff87046247feb074fd55c46e66a63895e..5d7174a8e67fc0c25c274d2a844b121bfb90a7b5 100644
--- a/pkg/analyzer/lib/src/summary/idl.dart
+++ b/pkg/analyzer/lib/src/summary/idl.dart
@@ -1034,6 +1034,12 @@ abstract class UnlinkedConst extends base.SummaryClass {
   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.
    */