Support for dart:typed_data

tool/input_sdk/private/rtti.dart

Index: tool/input_sdk/private/rtti.dart
diff --git a/tool/input_sdk/private/rtti.dart b/tool/input_sdk/private/rtti.dart
index 8694daa6e38033594b9add6644e6d9d50c09f808..f4d3562f759a3b279d9d66c402e5964986c972cf 100644
--- a/tool/input_sdk/private/rtti.dart
+++ b/tool/input_sdk/private/rtti.dart
@@ -93,9 +93,20 @@ checkPrimitiveType(obj) => JS('', '''(() => {
 })()''');
 
 runtimeType(obj) => JS('', '''(() => {
+  // Lookup primitive (int/double/string)
   let result = $checkPrimitiveType($obj);
   if (result !== null) return result;
-  return $obj.runtimeType;
+
+  // Lookup recorded type
+  result = $obj.runtimeType;

[Jennifer Messerly, 2016/02/10 00:20:30]

huh, the old code here looks broken. Shouldn't this go through:

    obj[dartx.runtimeType] ?

I'm not sure how user-defined Iterable/List types can work otherwise:

class MyIterable extends Iterable {
  get runtimeType => String; // Take that, type system! ;-)
}

[vsm, 2016/02/11 22:36:06]

For object properties, we either:

(1) use the unsymbolized name (obj.runtimeType)

or

(2) use staticDispatch (dart.runtimeType(obj))

The latter does the right thing on null.  There was bug here - we need to do
staticDispatch on potential extension types - fixed in codegen.

[Jennifer Messerly, 2016/02/11 23:04:57]

yeah, I mean, this is a bug in how the hand-coded runtime code here is written.
Compiler would've generated the right thing.

I don't think my example about will work. Anyway, I'll file a bug.

+  if (result) return result;
+
+  // Lookup extension type for native object
+  result = $obj[$_extensionType];

[Jennifer Messerly, 2016/02/10 00:20:30]

we can just go with realRuntimeType here, right? That's the fallback.

(I have some suggestions for that below)

[vsm, 2016/02/11 22:36:06]

Yeah, was try to avoid the redundant check on primitive types.  Just refactored
out the common part.

+  if (result) return result;
+
+  // TODO(vsm): Return JSObject?

[Jennifer Messerly, 2016/02/10 00:20:30]

(this may be moot based on realRuntimeType comment above) We should return
something. Object.runtimeType shouldn't return null.

Do we want to pretend all objects inherit from Dart's Object? If so,
core.Object's runtimeType is the universal fallback.

[vsm, 2016/02/11 22:36:06]

Removed

+  return null;
 })()''');
 
 getFunctionType(obj) => JS('', '''(() => {
@@ -111,12 +122,21 @@ getFunctionType(obj) => JS('', '''(() => {
 /// Currently this will return null for non-Dart objects.
 ///
 realRuntimeType(obj) => JS('', '''(() => {
+  // Lookup primitive type
   let result = $checkPrimitiveType($obj);
   if (result !== null) return result;
+
+  // Lookup recorded *real* type (not user definable runtimeType)
   // TODO(vsm): Should we treat Dart and JS objects differently here?
   // E.g., we can check if obj instanceof core.Object to differentiate.
   result = $obj[$_runtimeType];
   if (result) return result;
+
+  // Lookup extension type
+  result = $obj[$_extensionType];

[Jennifer Messerly, 2016/02/10 00:20:30]

Fallback to the constructor should find our type, that was set via `setType`.
That should be the extension type already. For example we set type to
`JSArray<T>` for Dart lists.

It may not be entirely obvious, but for JSArray<T> we set up the prototype chain
is like:

    obj --> JSArray<T>.prototype --> Array.prototype.

In one operation, we simultaneously record the correct Dart "real runtime type",
as well as getting the correctly typed (closing over "T") methods for
JSArray<T>, and in general, all of our operations (realRuntimeType, but anything
using reflection) will find the correct Dart metadata. Method tearoffs, etc.

If we don't set this up, things can go wrong:
* when we look up signatures/metadata it will break.
* we'd JSArray<dynamic> members which would be no good.

Because of the inheritance relationship, obj[_extensionType] will point back to
JSArray, from any JSArray.

[vsm, 2016/02/11 22:36:06]

Hmm, I think there are (at least) 3 interesting cases here:

(1) A generic extension type where we explicitly call setType.  E.g., <int>[1,
2, 3]
Here, the constructor is set up as you say.  Printing the real runtime type
shows JSArray<int> - good!

(2) A generic extension type where we don't call setType.  E.g., [1, 2, 3] or a
list we get from a JS API.
Here, the constructor is Array.  Printing the real runtime type shows
JSObject<Array> - a little weird.

(3) A non-generic extension type where we don't call setType (we can't as we get
it back from the DOM).   E.g., a Uint8List.
Here, the constructor is the native Uint8Array.  

In latter two cases, the _extensionType field maps back to the right type.

[Jennifer Messerly, 2016/02/11 23:04:57]

This shouldn't happen. setType must be called for a generic type. Without that,
you'll get the wrong generic methods, which is a much worse problem.

How are we getting generic types from JS? JS doesn't have reified generics ...
apologies if I'm super confused.
Since "setType" is how you populate _extensionType, I'm confused. :)

If I understand case (3), you want to map Array -> JSArray? Was that not working
before?

If it wasn't, the change here seems okay, but I don't get why you needed a
change to `setType`. That is what worries me.

+  if (result) return result;
+
+  // Fallback on constructor for class types
   result = $obj.constructor;
   if (result == Function) {
     // An undecorated Function should have come from