Support deserialized compilation of the empty program.

pkg/compiler/lib/src/common/resolution.dart

Index: pkg/compiler/lib/src/common/resolution.dart
diff --git a/pkg/compiler/lib/src/common/resolution.dart b/pkg/compiler/lib/src/common/resolution.dart
index 0286376b53d82f6797180edddca9889a74fcf509..a4b5f21e45c4726b0dad49ccec91b34c56de2165 100644
--- a/pkg/compiler/lib/src/common/resolution.dart
+++ b/pkg/compiler/lib/src/common/resolution.dart
@@ -182,8 +182,17 @@ class ListLiteralUse {
   }
 }
 
+/// Interface for the accessing the front-end analysis.
+abstract class Frontend {

[Siggi Cherem (dart-lang), 2016/04/15 15:42:14]

I ponder about the name here.... "Frontend" makes sense in the context of the
backend, but it might be too broad when all of
parsing/resolution/deserialization is part of a frontend. 

Here are some other ideas:

- "Resolver" (although it feels incorrect, since it might not be the one doing
the resolution when it loads the data from a serialized format).

- "ResolutionProvider"?

If you are not convinced about the latter, we can keep Frontend while we
brainstorm for other ideas.

[Johnni Winther, 2016/04/18 08:05:43]

'ResolutionProvider' is semantically the best but I don't like the 'Provider'
suffix. I don't particularly like 'Frontend' though it is fun to write
'compiler.backend.frontend' ;-)  Let's brainstorm a bit (added a TODO).

+  /// Returns the `ResolvedAst` for the [element].
+  ResolvedAst getResolvedAst(Element element);
+
+  /// Returns the [ResolutionImpact] for [element].
+  ResolutionImpact getResolutionImpact(Element element);
+}
+
 // TODO(johnniwinther): Rename to `Resolver` or `ResolverContext`.
-abstract class Resolution {
+abstract class Resolution extends Frontend {

[Siggi Cherem (dart-lang), 2016/04/15 15:42:14]

it doesn't' really matter, but for some reason this feels like it should be
`implements` rather than `extends`?

[Johnni Winther, 2016/04/18 08:05:43]

Done.

   Parsing get parsing;
   DiagnosticReporter get reporter;
   CoreTypes get coreTypes;