dart-sdk/pkg/dev_compiler
David Morgan 1d3fbbed7c Revert "Fix duration.toString() to conform the description"
This reverts commit 038e981f89.

Reason for revert: Breaks some tests; visible changes to some web UIs.

Original change's description:
> Fix duration.toString() to conform the description
> 
> Duration.toString() should return in a format of "HH:MM:SS.mmmmmm".
> But when `hours` is less than 10, toString() doesn't have the leading
> zero, which is "H:MM:SS.mmmmmm".
> 
> The corresponding co19 issue: https://github.com/dart-lang/co19/issues/733
> 
> Bug: https://github.com/dart-lang/sdk/issues/41737
> Change-Id: I2264171b2b37e89056695f7f821125a5f78d87fb
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151163
> Commit-Queue: Zichang Guo <zichangguo@google.com>
> Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>

TBR=lrn@google.com,zichangguo@google.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: https://github.com/dart-lang/sdk/issues/41737
Change-Id: I4d7ef5de9807e8e2b2a77c2171d1693b7527f671
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151848
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
2020-06-22 10:29:15 +00:00
..
bin [dartdevc] Properly encode Windows-style paths and paths with spaces for source maps 2019-07-10 16:49:22 +00:00
doc [dartdevc] add forwarding from old docs to new info 2019-12-10 22:53:26 +00:00
lib Added module information to metadata and use by frontend_sever 2020-06-20 00:40:35 +00:00
test Added module information to metadata and use by frontend_sever 2020-06-20 00:40:35 +00:00
tool Revert "Fix duration.toString() to conform the description" 2020-06-22 10:29:15 +00:00
web [dartdevc] Enforce more pedantic v1.9.0 lints and cleanup violations 2020-02-04 23:04:27 +00:00
.gitignore fix #626, add AMD module format and make it default 2016-08-25 09:39:36 -07:00
analysis_options.yaml [dartdevc] Enforce more pedantic v1.9.0 lints and cleanup violations 2020-02-04 23:04:27 +00:00
codereview.settings update codereview.settings for DDC 2016-11-14 15:28:50 -08:00
LICENSE.md Add LICENSE and corresponding headers 2015-02-24 15:02:26 -08:00
pubspec.yaml [dartdevc] Bump pedantic to v1.8.0 and apply new lints 2019-07-03 23:51:51 +00:00
README.md Remove dead/outdated lints from pkg/dev_compiler/README.md 2019-04-17 00:40:56 +00:00
STRONG_MODE.md [dartdevc] add forwarding from old docs to new info 2019-12-10 22:53:26 +00:00
USAGE.md Update USAGE.md 2017-02-15 10:52:42 -08:00

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.

Soundness and Restrictions

DDC is built upon Dart's sound type system. It only compiles programs that statically type check (i.e., no strong mode errors). It leverages static type checking to generate simpler, readable, and more idiomatic code with fewer runtime checks. In general, DDC is able to provide stronger type guarantees - i.e., soundness - than traditional Dart checked mode with significantly fewer runtime checks.

With strong mode, DDC is stricter than traditional Dart production mode or checked mode. Running existing Dart code on DDC will generally require fixing both static and runtime type errors.

For example, although the following snippet will run in production or checked mode, it will fail to compile with DDC:

var list = ["hello", "world"];  // Inferred as List<String> in strong mode
List<int> list2 = list;  // Static type error: incompatible types

On the other hand, the following snippet - which tries to mask the type error via casts - will compile with DDC, but fail with a runtime type error.

var list = ["hello", "world"];
List<Object> list2 = list;  // Generics are covariant.  No runtime check required.
List<int> list3 = list2;  // Implicit runtime downcast triggers error.

Modularity

DDC provides fast, incremental compilation based on standard JavaScript modules. 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 (e.g., ES6, AMD, or CommonJS). 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.

EcmaScript 6

DDC attempts to map Dart to idiomatic EcmaScript 6 (ES6) as cleanly as possible, and it relies heavily on static typing to do this. In general, where Dart concepts map directly to ES6, DDC generates code accordingly. For example, 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. In most cases, names are preserved and calling conventions are natural JavaScript ones.

There are some import caveats where Dart concepts do not 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 dynamic type), 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._x may map to a[_x] where _x is 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). In the near future, we expect to target all common modern browsers that support ES6. ES6 itself is in active development across all modern browsers, but at advanced stages of support:

kangax.github.io/compat-table/es6.