Clone AST nodes of default formal parameters prior to constant evaluation.

Clone AST nodes of default formal parameters prior to constant evaluation.

We need to clone these nodes for the same reason we need to clone the
nodes for constant variables--because once constant evaluation is
moved into the new task model, we will not necessarily have access to
the AST at the time we need to evaluate these constants (they may be
depended upon by constant invocation expressions in other libraries).

R=brianwilkerson@google.com

Committed: https://code.google.com/p/dart/source/detail?r=45568

[Paul Berry, 2015-05-05 22:25:29]

paulberry@google.com changed reviewers:
+ brianwilkerson@google.com

[Brian Wilkerson, 2015-05-05 22:43:02]

LGTM

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
File pkg/analyzer/lib/src/generated/element.dart (right):

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/element.dart:2068: extends
FieldFormalParameterElementImpl with ConstVariableElement {
I can't check the code right now, but if "ConstVariableElement" and
"PotentiallyConstVariableElement" are not instantiated, perhaps replacing
"Element" with "Mixin" would help make their use more clear.

[Paul Berry, 2015-05-06 15:35:14]

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
File pkg/analyzer/lib/src/generated/element.dart (right):

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/element.dart:2068: extends
FieldFormalParameterElementImpl with ConstVariableElement {
On 2015/05/05 22:43:02, Brian Wilkerson wrote:
> I can't check the code right now, but if "ConstVariableElement" and
> "PotentiallyConstVariableElement" are not instantiated, perhaps replacing
> "Element" with "Mixin" would help make their use more clear.

They're not instantiated directly, but they're used in a lot of places other
than "with" clauses, e.g. in the RHS of "as" expressions, as generic parameters
to collection classes, and in "implements" clauses.

If we wanted to make things clearer I would be more inclined to turn these into
abstract classes and move their implementations to brand new "Mixin" classes. 
That way most of the usages would still point to the "...Element" interfaces,
and only the usages in the "with" clauses would point to the "...Mixin" classes.
 But I'm not sure the benefit would be worth the effort.  Let me know if you
think it's worth trying.

[Brian Wilkerson, 2015-05-06 15:46:07]

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
File pkg/analyzer/lib/src/generated/element.dart (right):

https://codereview.chromium.org/1115993005/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/element.dart:2068: extends
FieldFormalParameterElementImpl with ConstVariableElement {
Given that ConstVariableElement and PotentiallyConstVariableElement are *not*
part of the public API, I don't think it's worth the effort. Sorry for the
noise.

[Paul Berry, 2015-05-06 15:51:47]

Committed patchset #1 (id:1) manually as 45568 (presubmit successful).