Fixes pkg/analysis_server/test/analysis/get_hover_test

Fixes pkg/analysis_server/test/analysis/get_hover_test
This was regressed by https://github.com/dart-lang/sdk/commit/af7359853f8f33b2febdcfa5beeb7a7dce115dce

Essentially, this restores the _functionTypesToFix tracking. Most function types are created later (in TypeResolverVisitor) but some are created earlier.

R=brianwilkerson@google.com, paulberry@google.com

Committed: https://github.com/dart-lang/sdk/commit/591a2fdd917c25fee7b138c2e5e64f8b0efa5e1a

[Jennifer Messerly, 2015-11-16 20:28:54]

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

[Paul Berry, 2015-11-16 20:32:21]

lgtm, but we probably should wait for Brian's review before committing, since
he's more familiar with this part of the resolver than I am.

[Jennifer Messerly, 2015-11-16 20:44:53]

On 2015/11/16 20:32:21, Paul Berry wrote:
> lgtm, but we probably should wait for Brian's review before committing, since
> he's more familiar with this part of the resolver than I am.

sounds good, I wonder if I should land this TBR in the meantime to unbreak
things. This is basically a partial revert (if you look at the original diff).

[Brian Wilkerson, 2015-11-16 20:53:04]

LGTM, with a few comments to think about. I'm fine with it as a temporary fix,
though.

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

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:2661: _functionTypesToFix = null;
Consider moving these six lines into a separate method that can be re-used in
visitClassTypeAlias (unless it's not needed there).

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:2685: _functionTypesToFix = new
List<ExecutableElementImpl>();
Can a ClassTypeAlias actually contain executable elements? If not, then I don't
think we need this here.

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:3046: // substitute those type
parameters later.
I assume the longer term fix is to either (a) create the collection in
visitFunctionDeclaration and to create the function elements on the way out
(like we do elsewhere) or (b) to move the collection creation and handling to
visitCompilationUnit and just defer the creation of function types until after
the element structure is complete.

[Jennifer Messerly, 2015-11-16 21:45:44]

Thanks!

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

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:2661: _functionTypesToFix = null;
On 2015/11/16 20:53:04, Brian Wilkerson wrote:
> Consider moving these six lines into a separate method that can be re-used in
> visitClassTypeAlias (unless it's not needed there).

Done. It does not appear to be needed in visitClassTypeAlias.

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:2685: _functionTypesToFix = new
List<ExecutableElementImpl>();
On 2015/11/16 20:53:04, Brian Wilkerson wrote:
> Can a ClassTypeAlias actually contain executable elements? If not, then I
don't
> think we need this here.

Restored it mainly because the original code had it. But yeah, I was wondering
the same thing--it doesn't seem like the list will ever get populated. Anyway I
added an assert(isEmpty) and it wasn't hit by tests, so I'll try removing this
for now. Hopefully it will stay gone this time. :)

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:3046: // substitute those type
parameters later.
On 2015/11/16 20:53:04, Brian Wilkerson wrote:
> I assume the longer term fix is to either (a) create the collection in
> visitFunctionDeclaration and to create the function elements on the way out
> (like we do elsewhere) or (b) to move the collection creation and handling to
> visitCompilationUnit and just defer the creation of function types until after
> the element structure is complete.

nice, yeah, I think either of those would work great. Do we always enter via
visitCompilationUnit? If so I might take a stab at that change right after this
(adding a test to show the generic nested function case that is fixed by it).

[Jennifer Messerly, 2015-11-16 21:46:37]

Committed patchset #2 (id:20001) manually as
591a2fdd917c25fee7b138c2e5e64f8b0efa5e1a (presubmit successful).

[Brian Wilkerson, 2015-11-16 21:55:30]

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

https://codereview.chromium.org/1450073002/diff/1/pkg/analyzer/lib/src/genera...
pkg/analyzer/lib/src/generated/resolver.dart:3046: // substitute those type
parameters later.
> Do we always enter via visitCompilationUnit?

I fairly sure that's the case, but I'd have to double check. We've talked before
about not creating elements for declarations within method / function bodies
until they're needed, but I don't believe that we've done that.