Fix incremental resolution of files referenced by multiple contexts.

pkg/analysis_server/lib/src/analysis_server.dart

Index: pkg/analysis_server/lib/src/analysis_server.dart
diff --git a/pkg/analysis_server/lib/src/analysis_server.dart b/pkg/analysis_server/lib/src/analysis_server.dart
index 5b8d9837801f8443211b9453c39080e05770b26e..39f45bb2345442a1eb3a112234438295fa09c769 100644
--- a/pkg/analysis_server/lib/src/analysis_server.dart
+++ b/pkg/analysis_server/lib/src/analysis_server.dart
@@ -836,20 +836,26 @@ class AnalysisServer {
    * Set the priority files to the given [files].
    */
   void setPriorityFiles(String requestId, List<String> files) {
+    // Note: when a file is a priority file, that information needs to be
+    // propagated to all contexts that analyze the file, so that all contexts
+    // will be able to do incremental resolution of the file.  See
+    // dartbug.com/22209.
     Map<AnalysisContext, List<Source>> sourceMap =
         new HashMap<AnalysisContext, List<Source>>();
     List<String> unanalyzed = new List<String>();
     files.forEach((file) {
-      AnalysisContext analysisContext = getAnalysisContext(file);
-      if (analysisContext == null) {
-        unanalyzed.add(file);
-      } else {
-        List<Source> sourceList = sourceMap[analysisContext];
-        if (sourceList == null) {
-          sourceList = <Source>[];
-          sourceMap[analysisContext] = sourceList;
+      AnalysisContext preferredContext = getAnalysisContext(file);
+      Source source = getSource(file);
+      bool contextFound = false;
+      for (AnalysisContext context in folderMap.values) {
+        if (context == preferredContext ||
+            context.getKindOf(source) != SourceKind.UNKNOWN) {

[scheglov, 2015/01/29 23:22:16]

It seems that if analysis isn't complete yet, and some external file is
referenced by a context, we will report an error, because we don't know yet if
the file is included into some context or not.

Maybe list of priority files also should be server-global.

[Paul Berry, 2015/01/30 00:19:45]

Aha, you're right!  I'd forgotten that we'd changed this part of the spec.  I
guess we forgot to change the code to match.  I'll make a follow up CL that
removes the error condition so that the behavior matches the spec.
That's a good idea.  It would fix some corner cases like priority files getting
forgotten about when the user does "reanalyze sources".  Let's discuss on Monday
when you and Brian are back from vacation.

+          sourceMap.putIfAbsent(context, () => <Source>[]).add(source);
+          contextFound = true;
         }
-        sourceList.add(getSource(file));
+      }
+      if (!contextFound) {
+        unanalyzed.add(file);
       }
     });
     if (unanalyzed.isNotEmpty) {
@@ -864,6 +870,9 @@ class AnalysisServer {
         sourceList = Source.EMPTY_ARRAY;
       }
       context.analysisPriorityOrder = sourceList;
+      // Schedule the context for analysis so that it has the opportunity to
+      // cache the AST's for the priority sources as soon as possible.
+      schedulePerformAnalysisOperation(context);

[scheglov, 2015/01/29 23:22:16]

I'm not sure we need this.

AFAIK we don't schedule any tasks in AnalysisContextImpl.
So, we will not prepare AST's in advance.
OTOH, if the analysis is already in progress, the next task will be priority
source analysis.

[Paul Berry, 2015/01/30 00:19:45]

Hmm, I tried the CL without this line at first, and it didn't work.  Let me dig
a little deeper to figure out why this line wasn't needed before revision
43163...

Ok, I understand now.  The reason it was working before revision 43163 is that
when a file becomes visible, editor makes two requests of the server: it sets
the file as a priority, and it requests navigation, occurrences, overrides,
outline, and highlights for the file.  Requesting the file as a priority
wouldn't cause any analysis to get scheduled.  But requesting navigation,
occurrences, etc. would cause setAnalysisSubscriptions() to call
getResolvedCompilationUnitToResendNotification(), which would call
context.resolveCompilationUnit2(), and that would compute the resolved AST
synchronously*.

(*It's a little scary, though, because there's a comment above
resolveCompilationUnit2() that says "This method cannot be used in an async
environment."  The analysis server sure seems like an async environment to me,
and yet things were working, so I'm not sure what that comment was warning
about.  I'll cc Brian on this review in case he has any insight.)

After revision 43163, and with this CL applied, but without the call to
schedulePerformAnalysisOperation, things don't work because
getResolvedCompilationUnitToResendNotification() only calls
context.resolveCompilationUnit2() for one context.  That means the other
contexts don't get a resolved AST, so the first attempt at incremental
resolution fails in those contexts.  (Later attempts at incremental resolution
succeed, though, because after a round of full analysis, the context knows that
the file is a priority file so it saves the resolved AST.)

By adding a call to schedulePerformAnalysisOperation here, I worked around the
problem by ensuring that all contexts would notice that they needed to compute a
resolved AST for the new priority file.

I'm going to go ahead with this CL for now, since it improves things and I'm not
sure what the correct approach is.  We should probably discuss this on Monday
and figure out if this is how we really want it to work.

[scheglov, 2015/01/30 00:25:49]

You are right, _getNextAnalysisTaskForSource handles priority sources
differently, and does prepare a resolved unit.

     });
     operationQueue.reschedule();
     Source firstSource = files.length > 0 ? getSource(files[0]) : null;