Generative constructor factories for native objects

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

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 part of dart2js;
 
 typedef ItemCompilationContext ItemCompilationContextCreator();
 
 class EnqueueTask extends CompilerTask {
   final ResolutionEnqueuer resolution;
@@ skipping 118 matching lines @@
       onRegisterInstantiatedClass(cls);
     });
   }
 
   void registerInstantiatedClass(ClassElement cls, TreeElements elements) {
     cls.ensureResolved(compiler);
     registerInstantiatedType(cls.rawType, elements);
   }
 
   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() {
     task.measure(() {
       // Run through the classes and see if we need to compile methods.
       for (ClassElement classElement in universe.instantiatedClasses) {
         for (ClassElement currentClass = classElement;
              currentClass != null;
              currentClass = currentClass.superclass) {
           processInstantiatedClass(currentClass);
@@ skipping 584 matching lines @@
     }
     CodegenWorkItem workItem = new CodegenWorkItem(
         element, itemCompilationContextCreator());
     queue.add(workItem);
   }
 
   void _logSpecificSummary(log(message)) {
     log('Compiled ${generatedCode.length} methods.');
   }
 }