fix #25794, infer parameter type from default value, in AST summaries

fix #25794, infer parameter type from default value, in AST summaries

(previous CL was https://github.com/dart-lang/sdk/commit/d43f6870b3a47fab5da3262fe28036af7f5c6bf5)

[Jennifer Messerly, 2016-06-25 00:31:56]

Description was changed from

==========
fix #25794, infer parameter type from default value, in AST summaries
==========

to

==========
fix #25794, infer parameter type from default value, in AST summaries

(previous CL was
https://github.com/dart-lang/sdk/commit/d43f6870b3a47fab5da3262fe28036af7f5c6bf5)
==========

[Jennifer Messerly, 2016-06-25 00:31:56]

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

[Jennifer Messerly, 2016-06-25 00:37:47]

Hi Paul, here's the follow up from earlier.

I-have-no-idea-what-I'm-doing so take a close look :)

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:2984: class
FunctionElementForLink_ParameterInitializer extends Object
this is almost entirely a copy+paste of FunctionElementForLink_Initializer used
for VariableElements.

perhaps I should introduce a common interface so code can be shared?

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:3015: _param.getAncestor((e) => e is
ClassElementForLink);
I think this was the only actual change

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:4063: DartType get declaredType {
this pattern more or less copy+paste from VariableElementForLink, aside from
keeping the handling of FunctionTypedParam

(the tests were good at catching stuff like that :) )

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:4092: new
TypeInferenceDependencyWalker().walk(_typeInferenceNode);
Aside -- I'm reusing logic from the static/top-level field inference.

Is this like, total overkill? It feels like it might be but I'm not sure if
there's a better approach :)

https://codereview.chromium.org/2092333002/diff/20001/pkg/analyzer/lib/src/su...
pkg/analyzer/lib/src/summary/link.dart:4120: void
link(CompilationUnitElementInBuildUnit compilationUnit) {
"link" method seems like the thing that actually fills in the type.

[Jennifer Messerly, 2016-06-30 19:17:56]

In retrospect I think this implementation was probably on the right track, since
it uses a similar trick as top-level field inference and reuses some of the
circularity detection. Unfortunately the implementation in normal
resolution/element summaries was not -- it fails for the
cyclic_default_value_test case:

foo([x = bar]) {}
bar([y = foo]) {}

I'm going to revert the (incorrect) previous fix and therefore, closing this one
for now too. But the CL is linked from the issue so we can take & run with it in
the future if needed.