Create `loadLibrary` function element eagerly.

Create `loadLibrary` function element eagerly.

Previously we created this element lazily (when requested) but this
didn't work well with the new task model, because creating the element
required calling back into the context and requesting full analysis of
`dart:async` (in order to get access to the Future type), and this
could lead to reentrant task execution.

Now we explicitly create the element in ResolveLibraryTypeNamesTask,
which allows us to get the Future type from the TypeProvider, avoiding
reentrancy.

Fixes #24627.

R=brianwilkerson@google.com

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

[Paul Berry, 2015-10-19 20:06:42]

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

[Brian Wilkerson, 2015-10-19 20:15:19]

LGTM

https://codereview.chromium.org/1405963005/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/context.dart (right):

https://codereview.chromium.org/1405963005/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/context.dart:634: assert(!driver.isTaskRunning);
Do we want to add this, or was this left over from debugging?

If we want to add it, consider putting it in computeResult just before asking
the driver to do some work.

[Paul Berry, 2015-10-19 20:31:30]

https://codereview.chromium.org/1405963005/diff/1/pkg/analyzer/lib/src/contex...
File pkg/analyzer/lib/src/context/context.dart (right):

https://codereview.chromium.org/1405963005/diff/1/pkg/analyzer/lib/src/contex...
pkg/analyzer/lib/src/context/context.dart:634: assert(!driver.isTaskRunning);
On 2015/10/19 20:15:19, Brian Wilkerson wrote:
> Do we want to add this, or was this left over from debugging?

This was added on purpose--in the absence of the bug fix, it changes the bug
from non-deterministic to deterministic by doing the reentrancy check prior to
checking whether the result has already been computed.  That should help us
catch the problem more quickly in the event of a regression.

> 
> If we want to add it, consider putting it in computeResult just before asking
> the driver to do some work.

Seems reasonable--that has the potential to catch more bugs.  I've moved it to
the top of computeResult, though (rather than just before asking the driver to
do some work) to preserve the determinism.

I've also added a comment to clarify what the check is for so that it doesn't
look like it was included by accident.

[Paul Berry, 2015-10-19 20:34:24]

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