The dart runtime files are roughly split around functional boundaries. Comments at the top of each file describe the function of the library. I'm not sure that these are 100% right yet, but they're closer. We may want to iterate on the organization.
The main dart runtime file just re-exports various symbols from the sub-libraries. It has hard dependencies on the other runtime files, some of which have soft (lazy) dependencies on SDK files. The generated code now depends on dart and dartx as a imported libraries, rather than as top level symbols.
This CL also includes some new code to make type representations a bit better. This is mostly in the new types.js file, which makes all of the non-instance types (dynamic, bottom, void, function types) subtypes of a common representation type. Among other things, they now have the correct runtime type (core.Type). Some of the type code has been rationalized around this a bit, but there is more left to do here. The setSignature code in classes.js now also places the correct runtime type on nominal (instance) types. There are new tests in the runtime_tests.js file to test for this.
The static object method code that implements the Object methods has not yet been updated to dispatch on type representations. I will do that in a separate CL.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1182653002
This bites us on Angular - dart:collection and angular's collection
(facade) lib smash on top of each other, silently causing issues.
We'll need a better naming convention - perhaps we should use the lib
name and require uniqueness.
Fixes#208R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1145243013
fixes#138, extension methods for Iterable/List injected as needed, regardless of how the methods started
fixes#142, extension methods and dynamic dispatch
small change that fixes#139, recognize that '.length' doesn't need an extension method
Also restores JSArray, moved the methods out of List, which is back to just being an interface.
NOTE: this removes the capability of types that mix native JS members and some Dart extension members, instead it now *hides* all JS members for these native types. We'll want to bring that feature back to support dart:html, so it's just a simplification for now. Should be easy to add that capability when we pull in dart:html for reals.
R=leafp@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1153003003
Reify dynamic as bottom or Object as appropriate in the generated code.
For general function types, dynamic parameters become bottom, and all other uses of dynamic become Object.
For concrete function types (the rtti attached to function objects) dynamic parameters also become Object.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1148333003
When we tear off a method, replace the obj.foo.bind(obj) pattern with dart.tearoff(obj, 'foo'), and the dart.bind(exp, 'foo') pattern with dart.tearoff(exp, 'foo'). This helper does both the bind and attaches rtti.
This CL also stops binding of static methods when they are town off, since I think this is unnecessary.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1142293002
For every class, we now generate a setSignature call which attaches properties to the constructor recording the method signatures, the static function signatures, and the names of all of the static methods. This call also attaches a getter to every static method which returns the type of the function. Methods are only decorated with runtime types when torn off. At a tear-off, the type is looked up in the constructor, and then attached to the bound function.
Top level functions and statement level functions get annotated with their type immediately after their declaration. We could consider moving all of the top level function annotations to the end of the file, but for now I've left it inline.
Closures (function expressions) get wrapped in calls to a dart.fn helper, with type information attached in one of various forms. This is currently the least attractive part of this CL. We may want to iterate on the syntax for this.
I've added some support for NSM checking to the dsend/dcall case as well.
We may wish to iterate on the syntax, and on the runtime representation of types, but this should move us forward from a functionality standpoint.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1138793002
Factored the load order logic into its own file, as it was easier to work with that way. We could definitely tweak the structure.
Also tried hoisting constants out to top level, but it's not quite ready yet, so splitting that work out into a separate CL.
(also fixes#152 about cleaning up lazyClass, and fixes#181 about static fields)
R=vsm@google.com
Review URL: https://codereview.chromium.org/1133593004
this was happening because we picked up an == operator from analyzer's Element
also adds an assert, because I took way too much time figuring out what the heck was happening there :)
R=vsm@google.com
Review URL: https://codereview.chromium.org/1139673005
readability regression, but fairly simple fix. looks okay in libraries with few imports, bad if they have a lot. ultimately I think this gets cleaned up as part of emitting modules + handling module lowering in JS codegen, see issue #34.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1122133003
static/top-levels don't need extension method, operator renames, or different slots* for private members
(static members are qualified by the static type, so they aren't ambiguous, e.g. Foo._foo and Bar._foo where Foo and Bar are in same/different libraries)
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1111863002
Hook the coercion reifier into the JS backend.
The principle observed changes in the output are from the downward type inference eliminating casts.
The coercion reifier changes in this CL in two ways.
The first is a relatively minor change to factor out the instrumented runtime calls. The reifier is now parameterized by a runtime object. If present, casts, wraps, and type object creation are delegated to the runtime. Otherwise the reifier just produces cast objects directly. The JS codegen always does the latter.
The larger change is an attempt to make the new AST nodes be resolved. This is principally done for the typedefs produced for casts - we're not using wrapping right now so I've left that for future if we want it. This is a bit painful - if we continue down this path I think I'll want to factor this out into a ResolvedAstBuilder or somesuch, but for now this seems to be working.
The rest of the changes are just plumbing in the coercion reifier and its dependencies into the js backend.
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1096583002
JSTemporary is now identified by instance, not its String name. This provides enough information to do renaming correctly and avoid the bug in #136.
The namer now considers all scopes where the temporary is visible, and chooses a name that doesn't conflict with other identifiers. Because it only considers scopes where the temp appears, it does less renaming that the previous version.
other changes:
* adds _emitSend for more consistent emitting of method calls. can't be used everywhere yet, but it unifies some things
* more consistent use of the core.String.* static pattern
* fix dynamic invoke to private members
* fix implicit-this to use emitMemberName, which makes them work with extension methods
* build the global extension method table up-front and optimize lookups (method name first, then subtype test if needed)
* teach the compiler that IsExpression never returns null
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1083763003
Vijay Menon