[analyzer] Don't panic if dart:core removed but not dart:async.

In VSCode, when the user hovers over a reference to `dart:core`
(e.g. an instance of a core type such as `String`), this triggers
VSCode to briefly open, and then close, one of the core files defining
the SDK; this in turn causes it to send notifications to the analysis
server to create and then destroy an overlay for the core SDK file.

This leads to a somewhat rare race condition: if the analyzer pumps
its event queue between receiving the notifications to create and
destroy the overlay, and there isn't adequate time in between these
two events for all active analysis drivers to re-build their library
readers, then what will happen is that
`LinkedElementFactory.removeLibraries` will get passed a `uriSet` that
contains `dart:core` but not `dart:async`. (The reason is because the
driver hasn't yet rebuilt the library cycles, so it doesn't know that
`dart:core` and `dart:async` are in the same cycle).

Before this change, `LinkedElementFactory.removeLibraries` contained a
safety check that would throw an exception if the `uriSet` ever
contained `dart:core` but not `dart:async`. Due to the race condition,
this safety check would occasionally fire, crashing the analyzer. (On
my machine, the crash would occur about once per day on average).

This safety check was incorrect (since it checked for a condition that
was thought never to occur, but in fact does occur). Also, it was not
necessary; since the only way for the race condition to occur is if
the driver hasn't yet rebuilt its library cycles, there is no harm in
removing just `dart:core` and not `dart:async`, as both have
previously been removed. And, indeed, the incorrect safety check has
always been followed by a (correct) safety check making sure that if
`dart:core` is ever removed, then after the removal, the set of
library readers is empty.

For the last month, I've been running a local build of the analyzer
with the incorrect safety check removed, and I haven't observed any
crashes.

Fixes #48051.

Bug: #48051
Change-Id: I611269ea7596cc63af5eb77d5baf641454a9d315
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428902
Reviewed-by: Konstantin Shcheglov <[email protected]>
Commit-Queue: Paul Berry <[email protected]>

Author: stereotype441

pkg/analyzer/lib/src/summary2/linked_element_factory.dart

@@ -255,12 +255,16 @@ class LinkedElementFactory {
     // If we discard `dart:core` and `dart:async`, we should also discard
     // the type provider.
     if (uriSet.contains(_dartCoreUri)) {
-      if (!uriSet.contains(_dartAsyncUri)) {
-        throw StateError(
-          'Expected to link dart:core and dart:async together: '
-          '${uriSet.toList()}',
-        );
-      }
+      // Most of the time, if the `uriSet` contains `dart:core`, then it will
+      // also contain `dart:async`, since `dart:core` and `dart:async` are part
+      // of the same library cycle. However, if an event triggers `dart:core` to
+      // be discarded at a time when no library cycle information has been built
+      // yet, then just `dart:core` will be in `uriSet`. This can happen, for
+      // example, if two events trigger invalidation of `dart:core` in rapid
+      // succession. Fortunately, if this happens, it is benign; since no
+      // library cycle information has been built yet, there is nothing that
+      // that needs to be discarded.
+
       if (_libraryReaders.isNotEmpty) {
         throw StateError(
           'Expected to link dart:core and dart:async first: '