Ensure interfaces are loaded.

dart/lib/compiler/implementation/elements/elements.dart

Index: dart/lib/compiler/implementation/elements/elements.dart
diff --git a/dart/lib/compiler/implementation/elements/elements.dart b/dart/lib/compiler/implementation/elements/elements.dart
index 432d835a3f4c120c8dc82a4093bea074d2af20cf..5a05bacced371c4e6b5710e287166ff85885efcd 100644
--- a/dart/lib/compiler/implementation/elements/elements.dart
+++ b/dart/lib/compiler/implementation/elements/elements.dart
@@ -440,8 +440,9 @@ class TypedefElement extends Element implements TypeDeclarationElement {
 
   Type computeType(Compiler compiler) {
     if (cachedType !== null) return cachedType;
-    cachedType = compiler.computeFunctionType(
-        this, compiler.resolveTypedef(this));
+    cachedType = new FunctionType(null, null, this);
+    cachedType.initializeFrom(
+        compiler.computeFunctionType(this, compiler.resolveTypedef(this)));
     return cachedType;
   }
 
@@ -883,6 +884,9 @@ class ClassElement extends ContainerElement
   Link<Type> interfaces = const EmptyLink<Type>();
   bool isResolved = false;
   bool isBeingResolved = false;
+  bool isLoadingSupertypes = false;
+  bool supertypesAreLoaded = false;

[Lasse Reichstein Nielsen, 2012/08/07 09:02:17]

Should we consider some kind of "state" type with "uninitialized",
"initializing", "initialized" states? I'm think I'm seeing this pattern a little
too often!

+
   // backendMembers are members that have been added by the backend to simplify
   // compilation. They don't have any user-side counter-part.
   Link<Element> backendMembers = const EmptyLink<Element>();
@@ -921,7 +925,12 @@ class ClassElement extends ContainerElement
   Link<Type> get typeVariables() => type.arguments;
 
   ClassElement ensureResolved(Compiler compiler) {
-    compiler.resolveClass(this);
+    if (!isResolved && !isBeingResolved) {
+      isBeingResolved = true;
+      compiler.resolver.resolveClass(this);

[Lasse Reichstein Nielsen, 2012/08/07 09:02:17]

This looks like the job for a work queue. 
Can't we just queue this instead of doing it immediately?
It seems that all this boolean-fiddling is to handle recursive dependencies, so
we must be able to handle that sometimes the resolving isn't completely done
when we return. Why not just do that all the time then?
Then we just need one bit: isResolved, and the "being resolved" is represented
by being in the queue.

+      isBeingResolved = false;
+      isResolved = true;
+    }
     return this;
   }
 
@@ -939,9 +948,25 @@ class ClassElement extends ContainerElement
       if (e.modifiers.isStatic()) continue;
       return e;
     }
+    if (isInterface()) {
+      return lookupSuperInterfaceMember(memberName, getLibrary());
+    }
     return null;
   }
 
+  Element lookupSuperInterfaceMember(SourceString memberName,
+                                     LibraryElement fromLibrary) {
+    for (Type t in interfaces) {
+      Element e = t.element.lookupLocalMember(memberName);
+      if (e === null) continue;
+      // Private members from a different library are not visible.
+      if (memberName.isPrivate() && fromLibrary !== e.getLibrary()) continue;
+      // Static members are not inherited.
+      if (e.modifiers.isStatic()) continue;
+      return e;
+    }
+  }
+
   /**
    * Find the first member in the class chain with the given
    * [memberName]. This method is NOT to be used for resolving