Generative constructor factories for native objects

sdk/lib/_internal/compiler/implementation/enqueue.dart

Index: sdk/lib/_internal/compiler/implementation/enqueue.dart
diff --git a/sdk/lib/_internal/compiler/implementation/enqueue.dart b/sdk/lib/_internal/compiler/implementation/enqueue.dart
index e489fb187294d571ad7d413a97c685b2ec130e64..f674e5b0b7601bc5c9704d9f94d169fafad97bda 100644
--- a/sdk/lib/_internal/compiler/implementation/enqueue.dart
+++ b/sdk/lib/_internal/compiler/implementation/enqueue.dart
@@ -136,8 +136,27 @@ abstract class Enqueuer {
   }
 
   void registerTypeLiteral(Element element, TreeElements elements) {
+    assert(isResolutionQueue);
     registerInstantiatedClass(compiler.typeClass, elements);
     compiler.backend.registerTypeLiteral(element, this, elements);
+    registerEscapingConstructorsOfClass(element);
+  }
+
+  void registerEscapingConstructorsOfClass(ClassElement classElement) {
+    // Web component classes have constructors that are escaped to the host
+    // environment.
+    classElement.forEachMember(
+        (ClassElement enclosingClass, Element member) {
+          if (member.isGenerativeConstructor()) {
+            // isNativeOrExtendsNative is valid only after resolution.
+            if (isResolutionQueue
+                || Elements.isNativeOrExtendsNative(classElement)) {
+              registerStaticUse(member);

[ahe, 2013/10/03 07:44:49]

This means that all constructors of type literals are enqueued during
resolution. As far as I can tell, this is to support document.register which I
maintain is a really poor fit for Dart, especially dart2js.

I cannot in good conscience approve any changes that cripples dart2js further in
an attempt to support document.register. I think the metadata approach in
polymer.dart is far superior, and I see no reason why we need document.register
to implement polymer.dart.

[sra1, 2013/10/03 17:00:23]

I think that isNativeOrExtendsNative can be made to work during resolution to
reduce the set.
The metadata approach uses metadata to figure out the arguments to
document.register.
The JavaScript layer document.register is the only API to the browser, we can't
implement anything without that.

When we use Polymer annotations, we will also need to filter the classes that
may be passed to document.register.
I hope we don't have to analyze all the annotations during resolution to figure
out which classes have annotations that will cause some code in some imported
library to ask for ClassMirror.reflectedType on the annotation target
(https://code.google.com/p/dart/issues/detail?id=12607) to pass to
document.register. 

+            }
+          }
+        },
+        includeBackendMembers: false,
+        includeSuperAndInjectedMembers: false);
   }
 
   bool checkNoEnqueuedInvokedInstanceMethods() {