Fix async/await type checking in analyzer.

Fix async/await type checking in analyzer.

This required making the "async" library into TypeProvider so that we
can create Future<...> types when doing resolution and error/hint
checking.

BUG=21888, 22053, 22091, 22092, 22160, 22164
R=brianwilkerson@google.com

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

[Paul Berry, 2015-02-02 18:15:20]

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

[Brian Wilkerson, 2015-02-02 19:41:48]

LGTM

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/engine.dart (right):

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/engine.dart:5471: // isn't actually being
imported.
I don't think this is (or should be) necessary under the current implementation
because core indirectly imports async (via convert), so if the core element
model has been built then the async element model will have also been built.

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/resolver.dart (right):

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/resolver.dart:75: : _futureNullType =
typeProvider.futureType.substitute4(
Should we make Future<Null> directly accessible through the typeProvider so that
it doesn't need to be re-created as often?

[Paul Berry, 2015-02-02 20:55:38]

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/engine.dart (right):

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/engine.dart:5471: // isn't actually being
imported.
On 2015/02/02 19:41:48, Brian Wilkerson wrote:
> I don't think this is (or should be) necessary under the current
implementation
> because core indirectly imports async (via convert), so if the core element
> model has been built then the async element model will have also been built.

Hmm, your reasoning seems valid.  However, if I remove this code I get a lot of
unit test failures.  Perhaps in the various mock SDK's we use for unit testing,
core doesn't indirectly import async.

Even if we can figure out a way to remove this code and fix the unit test
failures, I'm not sure it would be a net win, since then we would be in a
situation where analyzer's correctness depends on an the existence of an
implicit import relationship in the SDK.  I'd rather avoid that if possible,
since it's conceivable (though not particularly likely) that a future version of
the SDK won't have this implicit import relationship, causing subtle breakages.

If I'm not mistaken this code is going to go away when we move to the new task
model, and I'm hoping that when we do that we'll be able to represent the
dependency on async in a less hacky way.  So for now I think I will land the
code as is.  But I've updated the TODO comment to capture this discussion.  If
you feel strongly that this is a bad way to go, I'll be happy to discuss it
tomorrow.

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
File pkg/analyzer/lib/src/generated/resolver.dart (right):

https://codereview.chromium.org/898513002/diff/20001/pkg/analyzer/lib/src/gen...
pkg/analyzer/lib/src/generated/resolver.dart:75: : _futureNullType =
typeProvider.futureType.substitute4(
On 2015/02/02 19:41:48, Brian Wilkerson wrote:
> Should we make Future<Null> directly accessible through the typeProvider so
that
> it doesn't need to be re-created as often?

That's a good idea.  I need to do more work in this area to fix async* and
sync*, so I'll fold that into my next CL.

[Paul Berry, 2015-02-02 20:58:54]

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