Handle dynamic as bottom inside of function type reps

Handle dynamic as bottom inside of function type reps.

This changes the way we handle dynamic at runtime to be more correct and cleaner.  We now simply emit dynamic as dynamic instead of as core.Object.  There are now two ways to construct a function type: one can construct a fuzzy function type (the default), or a definite function type.  The constructor for a fuzzy function type replaces all uses of dynamic with bottom.  This function type is used for all type annotations.  Definite function types do not replace dynamic with bottom.  These only occur as the runtime type of actual functions, for which we really know the type. Because we now eagerly sort this out when we create the function type, the subtyping code doesn't need to deal with this.

This allows some additional subtyping: closures which actually are typed to take dynamic would previously not have been allowed to be cast to something with a concrete argument type.  Now this is allowed (see the change in runtime_tests.js for an example of this).

This fixes #107.

BUG=
R=vsm@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/ed8722d9b1b9850395b658acf55fa5f3a0195c0c

[Leaf, 2015-06-17 21:55:58]

leafp@google.com changed reviewers:
+ jmesserly@google.com, vsm@google.com

[vsm, 2015-06-17 22:43:13]

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js
File lib/runtime/_rtti.js (right):

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js#newcod...
lib/runtime/_rtti.js:118: function getFunctionType(obj) {
Do we still use this method?  I wrote this before you actually stored function
types properly.

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js#newcod...
lib/runtime/_rtti.js:120: let args = Array.apply(null, new
Array(obj.length)).map(() => classes.dynamic);
(nit: length) Should this be types.dynamic?

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/dart/_intercept...
File lib/runtime/dart/_interceptors.js (right):

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/dart/_intercept...
lib/runtime/dart/_interceptors.js:208: dart.as(combine,
dart.functionType(dart.dynamic, [dart.dynamic, E]));
Is the "dynamic" first arg param Top or Bottom in this context?  Would we need a
dinvoke to call combine at this point?

[Leaf, 2015-06-17 22:53:08]

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js
File lib/runtime/_rtti.js (right):

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js#newcod...
lib/runtime/_rtti.js:118: function getFunctionType(obj) {
On 2015/06/17 22:43:13, vsm wrote:
> Do we still use this method?  I wrote this before you actually stored function
> types properly.

Currently I believe that it will make javascript functions be treated as having
the least specific function type of the appropriate arity (Top^n => Bot).  I'm
not sure if we want or need this right now.  See realRuntimeType below for the
only call site.

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/_rtti.js#newcod...
lib/runtime/_rtti.js:120: let args = Array.apply(null, new
Array(obj.length)).map(() => classes.dynamic);
On 2015/06/17 22:43:13, vsm wrote:
> (nit: length) Should this be types.dynamic?

Yes, fixed but forgot to upload before sending.  good catch.  :)

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/dart/_intercept...
File lib/runtime/dart/_interceptors.js (right):

https://codereview.chromium.org/1195523002/diff/1/lib/runtime/dart/_intercept...
lib/runtime/dart/_interceptors.js:208: dart.as(combine,
dart.functionType(dart.dynamic, [dart.dynamic, E]));
On 2015/06/17 22:43:13, vsm wrote:
> Is the "dynamic" first arg param Top or Bottom in this context?  Would we need
a
> dinvoke to call combine at this point?

Dynamic here will be treated as bottom, since function types are by default
fuzzy.  It's only things created via definiteFunctionType which retain dynamic
on the arguments.  For correctness this would need to be called with a dinvoke
here.

[vsm, 2015-06-17 23:14:38]

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_classes.js
File lib/runtime/_classes.js (right):

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_classes.js...
lib/runtime/_classes.js:174: return types.definiteFunctionType.apply(null,
parts);
Should these really be definite for instance methods?  See #129.

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_types.js
File lib/runtime/_types.js (right):

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_types.js#n...
lib/runtime/_types.js:130: * this logic in multple places.
multple -> multiple

[vsm, 2015-06-17 23:42:33]

lgtm after chatting with leaf offline

[Leaf, 2015-06-17 23:44:37]

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_classes.js
File lib/runtime/_classes.js (right):

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_classes.js...
lib/runtime/_classes.js:174: return types.definiteFunctionType.apply(null,
parts);
On 2015/06/17 23:14:38, vsm wrote:
> Should these really be definite for instance methods?  See #129.

I don't think this affects #129.  #129 has to do with what static type we use,
and how we generate code (e.g. either a dinvoke or not).  So in the checker, we
need to decide whether to expose methods as having a fuzzy type or a definite
type.  Currently I believe that we expose them as fuzzy, which is why the
override in #129 is allowed (and why a dinvoke is needed).

This on the other hand has to do with what runtime type we assign.  It is always
the case that definiteFunctionType(args) <: functionType(args), and so any
runtime type checks that used to succeed will still succeed (the runtime type
only appears on the left hand side of subtype checks).  Finally, it is always
safe to use a function at its definite type, since it is, by construction,
correct.

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_types.js
File lib/runtime/_types.js (right):

https://codereview.chromium.org/1195523002/diff/20001/lib/runtime/_types.js#n...
lib/runtime/_types.js:130: * this logic in multple places.
On 2015/06/17 23:14:38, vsm wrote:
> multple -> multiple

Done.

[Leaf, 2015-06-17 23:46:43]

Committed patchset #3 (id:40001) manually as
ed8722d9b1b9850395b658acf55fa5f3a0195c0c (presubmit successful).