Ensure that a complete library element has constants evaluated (issue 24890)

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 6a5ace1f3ee8e8b5febf0bcd558c579adbf97ae9..bc8643294693fcbb8313b162fc2c2300cc73a300 100644
--- a/pkg/analysis_server/lib/src/analysis_server.dart
+++ b/pkg/analysis_server/lib/src/analysis_server.dart
@@ -34,6 +34,7 @@ import 'package:analyzer/src/generated/sdk.dart';
 import 'package:analyzer/src/generated/source.dart';
 import 'package:analyzer/src/generated/source_io.dart';
 import 'package:analyzer/src/generated/utilities_general.dart';
+import 'package:analyzer/src/task/dart.dart';
 import 'package:analyzer/src/util/glob.dart';
 import 'package:plugin/plugin.dart';
 
@@ -1321,7 +1322,7 @@ class AnalysisServer {
     }
     // if library has not been resolved yet, the unit will be resolved later
     Source librarySource = librarySources[0];
-    if (context.getLibraryElement(librarySource) == null) {
+    if (context.getResult(librarySource, LIBRARY_ELEMENT8) == null) {

[Paul Berry, 2015/11/30 20:44:35]

I'm also concerned about the leakage of LIBRARY_ELEMENT8 into analysis server. 
Why is this necessary?  At first blush it seems like we ought to be able to keep
doing getLibraryElement, but I'm assuming you have a good reason why that won't
work.

[Brian Wilkerson, 2015/11/30 21:35:39]

As I'm sure you know, the method getLibraryElement does not do any work. If the
LIBRARY_ELEMENT has been computed, then it is returned. If not, then null is
returned.

The state that used to be known as LIBRARY_ELEMENT was reliably computed for
libraries in the SDK. That state has now been renamed to LIBRARY_ELEMENT_8 and
is still reliably computed for libraries in the SDK. The state that is now known
as LIBRARY_ELEMENT is *not* always computed. As a result, methods like this one
started getting null when they used to get a non-null value.

[eernst, 2015/12/14 10:01:39]

DBC: If LIBRARY_ELEMENT8 and maybe other, similarly named entities are too
private for widespread usage in the analysis_server, and if usages have common
traits (`context.getResult(librarySource, LIBRARY_ELEMENT8)` is used more than
once, for instance) then it might be helpful to encapsulate those usages into a
couple of functions (which would then be called from the locations where
LIBRARY_ELEMENT8 is now used explicitly). This would at least centralize the
locations where changes will be needed if it is renamed again, or if it changes
semantics. But I do recognize that the usages are so diverse that these
functions would easily deteriorate into a single getter that returns
LIBRARY_ELEMENT8, which would only provide the meaningful name and no
abstraction.

[Brian Wilkerson, 2015/12/14 15:38:26]

Absolutely. We had a discussion in the office about this and agreed that there
are probably a small number of the LIBRARY_ELEMENTn states that would be useful
to clients, and that we needed to (a) identify which states those are and (b)
design an API to make them available. But we also decided not to hold up fixing
this bug until we could finish that design work. I plan to address the need for
this API in a future CL.

       return null;
     }
     // if library has been already resolved, resolve unit