Make backend.setAnnotations (mostly) handle LibraryEntities.

pkg/compiler/lib/src/kernel/world_builder.dart

Index: pkg/compiler/lib/src/kernel/world_builder.dart
diff --git a/pkg/compiler/lib/src/kernel/world_builder.dart b/pkg/compiler/lib/src/kernel/world_builder.dart
index 5e9272a55585b5cb4b4b2fbf67c50c6c88cd31c0..3ccc6aef2b68b85ff3b63863368f4d4e03c652e1 100644
--- a/pkg/compiler/lib/src/kernel/world_builder.dart
+++ b/pkg/compiler/lib/src/kernel/world_builder.dart
@@ -105,6 +105,8 @@ class KernelWorldBuilder extends KernelElementAdapterMixin {
   @override
   native.BehaviorBuilder get nativeBehaviorBuilder => _nativeBehaviorBuilder;
 
+  KernelLookup get lookup => new KernelLookup._internal(_libraryMap, _classMap);
+
   LibraryEntity lookupLibrary(Uri uri) {
     KLibraryEnv libraryEnv = _env.lookupLibrary(uri);
     return _getLibrary(libraryEnv.library, libraryEnv);
@@ -522,6 +524,26 @@ class KernelWorldBuilder extends KernelElementAdapterMixin {
   }
 }
 
+/// A glorified combination of maps for looking up the correspondence between a
+/// particular K-Entity and its corresponding Kernel Element object.
+class KernelLookup {

[Emily Fortuna, 2017/04/19 00:59:55]

I'm guessing we want to have some sort of super interface where we can do the
same thing for the AST nodes (instead of looking up on the element->nodes
themselves)? I wanted to check before implementing too much though.

[Johnni Winther, 2017/04/19 08:39:51]

This functionality is already in KernelWorldBuilder (through libraryIndex,
classIndex, etc). Just leave out this class, I'll merge the
_KernelAnnotationProcessor with the code I already have.

[Siggi Cherem (dart-lang), 2017/04/19 15:36:29]

Ah! some questions for Johnni...

1. is the idea to mimic what you have in lookupLibraryMember? (i.e. you would
add a similar method like lookupLibraryKernelMember and directly return the ir
node?)

2. I'd like to split KernelWorldBuilder or rename it. I feel like we should have
a simple mechanism to map elements and nodes that is independent of a world
builder - I imagine we'll create a world builder later in the compiler pipeline,
and we can make some pieces of the compiler (like the annotation processor)
independent of the world. Do you agree?

[Emily Fortuna, 2017/04/19 22:35:46]

Okay. You're still not exposing the ir.Library and ir.Classes, though. I added
methods to do that. Please let me know if you had envisioned something
different.

Please also fill us in given Siggi's questions.

[Johnni Winther, 2017/04/20 07:19:27]

1. I want IR based reasoning to be confined to the kernel/world_builder library.
History shows that if we expose the internal structures we will use them
everywhere (think of how we use AST nodes). So _no_ public methods returning IR
nodes, if avoidable.

2. You rarely need IR nodes without their relation to the element model, that is
what KernelWorldBuilder is for. (And I will soon rename it to
KernelElementBuilder to reflect that more clearly).

+  Map<KLibrary, ir.Library> _libraryMap = <KLibrary, ir.Library>{};
+  Map<KClass, ir.Class> _classMap = <KClass, ir.Class>{};
+
+  KernelLookup._internal(Map<ir.Library, KLibrary> reverseLibraryMap,
+      Map<ir.Class, KClass> reverseClassMap) {
+    for (ir.Library library in reverseLibraryMap.keys) {
+      _libraryMap[reverseLibraryMap[library]] = library;
+    }
+    for (ir.Class class_entity in reverseClassMap.keys) {
+      _classMap[reverseClassMap[class_entity]] = class_entity;
+    }
+  }
+
+  ir.Class lookupClass(KClass entity) => _classMap[entity];
+  ir.Library lookupLibrary(KLibrary entity) => _libraryMap[entity];
+}
+
 /// Environment for fast lookup of program libraries.
 class KEnv {
   final ir.Program program;