MarkZ
ba90daf304
This new update adds fixes + tests for cross-module super mixins. Super getters can refer to mixins compiled in other modules, so we need to expose all mixin names to make them accessible from their enclosing library.
This is a reland of commit e4c4d0f839
Original change's description:
> [ddc] Overhauling tearoff equality and identity.
>
> Hot reload requires DDC to update how its tearoffs are represented. Tearoffs obey the following conventions:
> * Instance tearoffs are never identical
> * Tearoffs with the same object target and name have the same hash code (even if they resolve to different functions across hot reloads)
> * Two separate tearoffs of the same member are equal
>
> To support this, tearoff equality must not depend on the bound object and method but a composite of the bound object, torn off member name, and the exact class/object from which the member was torn off.
>
> Notable changes:
> * Methods' immediately bound targets are emitted with member signatures. This is required to determine the bound targets for instance and dynamic tearoffs. Bound targets are identified by `libraryUri:class` strings.
> * `applyMixin` passes in a 'true' bound target. This is because mixin applications' members are considered children of their 'on' class (not the mixed in class) wrt equality/hashCode.
> * `bind` is modified to pass in its 'true' bound object to support mixins' super getters.
> * `tearoff` and `staticTearoff` are modified to accept a bound target string (only required for static tearoffs, as they are bound at tearoff-creation-time).
> * Static tearoffs avoid using their bound object for hashcode and equality, as these libraries may be wrapped in proxy objects.
> * Tearoff equality and hashCode are updated to consider bound object, bound name, and its bound method's immediate target.
> * 'noSuchMethod' and 'toString' methods are always accessed through their extension property during signature lookups.
>
>
> Change-Id: Ica5501b6860c605db50aa945bafb6802a7317511
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406723
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I645992030f9106c158426412387ddecafc78e3f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415102
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
The Dart Dev Compiler (DDC) is a fast, modular compiler that generates modern JavaScript (EcmaScript 6). Its primary use today is to support fast, iterative development of Dart web applications for Chrome and other modern browsers.
Support
DDC is meant to be used by build systems like bazel, build_web_compilers and
flutter_tools under the hood. This compiler is not meant to be used by
application developers directly.
While at times the code generated by this compiler may be readable, the representation is not meant to be stable and can break with time. For that reason we do not recommend using this compiler to export Dart as a JavaScript module.
The recommended approach to compile Dart to JavaScript is to use dart compile js instead. If you intend to make a public JavaScript API based on a Dart
implementation, such API should be declared explicitly using the standard
Dart-JSInterop mechanisms.
Implementation details
Modularity
Unlike Dart2JS, DDC does not require an entire Dart application. Instead, it operates modularly: it compiles a set of Dart files into a JavaScript module. A DDC compilation step requires a set of input Dart files and a set of summaries of dependencies. It performs modular type checking as part of this compilation step, and, if the input type checks, it generates a JavaScript module. The browser (i.e., the JavaScript runtime) loads and links the generated modules when running the application. During development, a compilation step only needs to be rerun if the Dart files or summaries it relies upon change. For most changes, only a very small part of your code will require recompilation. Moreover, modules that are unchanged can be cached in the browser.
Representation
Currently Dart classes are mapped to ES6 classes, Dart fields to ES6 properties, Dart getters/setters to ES6 getters/setters, Dart methods to ES6 methods, and so on. Often names are preserved and calling conventions are natural JavaScript ones.
Some Dart concepts don't map directly:
-
Libraries. Multiple Dart libraries are mapped to a single JS module. Each library appears as a first class object in the generated JS module, with its top-level symbols as members. We currently use a heuristic (based upon file paths) to ensure unique naming of generated library objects.
-
Generics. Dart generics are reified, i.e., they are preserved at runtime. Generic classes are mapped to factories that, given one or more type parameters, return an actual ES6 class (e.g.,
HashMap$(core.String, core.int)produces a class that represents a HashMap from strings to ints). Similarly, generic methods are mapped to factories that, given one or more type parameters, return a method. -
Dynamic. DDC supports dynamically typed code (i.e., Dart's
dynamictype), but it will typically generate less readable and less efficient ES6 output as many type checks must be deferred to runtime. All dynamic operations are invoked via runtime helper code. -
Constructors. Dart supports multiple, named and factory constructors for a given class with a different initialization order for fields. Today, these are mapped to instance or static methods on the generated ES6 class.
-
Private members. Dart maps private members (e.g., private fields or methods) to ES6 symbols. For example,
a._xmay map toa[_x]where_xis a symbol only defined in the scope of the generated library. -
Scoping. Dart scoping rules and reserved words are slightly different than JavaScript. While we try to preserve names wherever possible, in certain cases, we are required to rename.
In general, the current conventions (i.e., the Application Binary Interface or ABI in compiler terminology) should not be considered stable. We reserve the right to change these in the future.
Browser support
DDC currently supports Chrome stable (though users have had success running on FireFox and Safari).