Add annotations on native fields and methods

Add annotations on native fields and methods

Automatically add annotations on native fields and methods where the
type is known to be a subtype of the API type.  Example: The API is
declared as returning List<Node>, but we know from the IDL that this
is implemented by the native type _NodeList.

Also add some manual annotations.

The optimization is still hidden behind --enable-native-live-type-analysis

Committed: https://code.google.com/p/dart/source/detail?r=15181

[sra1, 2012-11-20 06:04:57]

This is the main win from native type liveness analysis.
Half of the native classes are found to be unused in swarm.

This is the effect of --enable-native-live-type-analysis:

swarm bytes    742554 592866
.. from html   211014 115015
.. from svg     44071  25392
native classes    528    261

[ngeoffray, 2012-11-20 08:50:13]

This is very nice!

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
File sdk/lib/html/templates/html/impl/impl_Element.darttemplate (right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
sdk/lib/html/templates/html/impl/impl_Element.darttemplate:621: @Creates('Null')
 // Set from Dart code; does not instantiate a native type.
Why do you need this one?

[sra1, 2012-11-20 09:01:42]

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
File sdk/lib/html/templates/html/impl/impl_Element.darttemplate (right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
sdk/lib/html/templates/html/impl/impl_Element.darttemplate:621: @Creates('Null')
 // Set from Dart code; does not instantiate a native type.
On 2012/11/20 08:50:13, ngeoffray wrote:
> Why do you need this one?

xtag is really a Dart-only field used by the WebComponents compiler.

The default (safe) assumption is that accessing a native field will create any
native class that is a subtype of the field's declared type.

This field is always assigned from Dart code so there is no path hidden in the
browser that might create an instance x that satisfies "x is T" where T is the
declared type.

@Create('Null') is a way of expressing this without inventing a new annotations.

[vsm, 2012-11-20 18:33:46]

lgtm

Nice results!

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
File sdk/lib/html/dart2js/html_dart2js.dart (right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:1131: @Returns('_CSSRuleList')
@Creates('_CSSRuleList')
Does @Returns imply @Creates?

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:12254: @Creates('Database')
@Creates('DatabaseSync')
FWIW, the first is redundant with the return type.  Does this really create a
DatabaseSync?

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:13215: @Creates('=List')
What's the significance of the "="?

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
File
sdk/lib/html/templates/html/dart2js/factoryprovider_MutationObserver.darttemplate
(right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
sdk/lib/html/templates/html/dart2js/factoryprovider_MutationObserver.darttemplate:10:
@Creates('MutationRecord')
Should MutationRecord be somehow specified on MutationCallback instead?  E.g.,
if no passed in callback uses the MutationRecord, the type doesn't really leak
anywhere else.

[sra1, 2012-11-20 19:26:33]

I will put or move some comments on to the declaration of Creates and Returns.

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
File sdk/lib/html/dart2js/html_dart2js.dart (right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:1131: @Returns('_CSSRuleList')
@Creates('_CSSRuleList')
On 2012/11/20 18:33:46, vsm wrote:
> Does @Returns imply @Creates?

No.  There is no cross-use of the annotations.
I could change that.

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:12254: @Creates('Database')
@Creates('DatabaseSync')
On 2012/11/20 18:33:46, vsm wrote:
> FWIW, the first is redundant with the return type.  Does this really create a
> DatabaseSync?

1. If you give any Creates annotation, you must give them all.  Otherwise you
cant stop the pollution due to a a bad declared return type like Object.

2. The callback has both, which unions to Object, so the callback is causing
pollution.

3. I'm not sure if we can actually get the Sync version so this is conservative,
based on the types.

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/dart2js/h...
sdk/lib/html/dart2js/html_dart2js.dart:13215: @Creates('=List')
On 2012/11/20 18:33:46, vsm wrote:
> What's the significance of the "="?

=List is a special hack to name JavaScript Array.
=Object is a special hack to name a plain JS Object.

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
File
sdk/lib/html/templates/html/dart2js/factoryprovider_MutationObserver.darttemplate
(right):

https://chromiumcodereview.appspot.com/11415067/diff/1/sdk/lib/html/templates...
sdk/lib/html/templates/html/dart2js/factoryprovider_MutationObserver.darttemplate:10:
@Creates('MutationRecord')
On 2012/11/20 18:33:46, vsm wrote:
> Should MutationRecord be somehow specified on MutationCallback instead?  E.g.,
> if no passed in callback uses the MutationRecord, the type doesn't really leak
> anywhere else.

1. Inference through the callback is broken for two reasons - (a) lack of stored
type parameters in the compiler causes all Lists to be inferred (b) no concrete
type implementing List<MutationRecord>.

(a) can be fixed.  (b) is how we want it - you only create instances of T from
List<T> when you access the list.  The type inference is based on concrete
types, which have precise non-parameter types on operator[].  It would be much
more complicated to implement with non-concrete types.  In the few places that
actually return JS array we have no concrete type with a specialized type on the
accessors, so we make up for that manually.

2. If you give one @Creates you must give them all - i.e. specifying
MutationObserver inhibits the use of the (overly general) types inferred from
the callback's type.