This:
- Ensures that a given AST is processed once per context, avoiding AST caching issues and redundant work
- Associates file errors with their library instead of the entry point - we now only generate these once across different entry points
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1376123004 .
this also implements multitest support, which fixes#280
Fixes some other preexisting bugs:
* MetaLets did not simplify themselves correctly in some nested cases
* Library prefixed identifiers did not work as lvalues in opassign
* dsetindex/dput/[]= methods did not return a value
* checker did not correctly handle invalid constructor field initializers
* cascades did not correctly work with method invocations(?)
* postfix ++/-- did not correctly generate lvalues in some cases
The good news: because this reuses on our existing lvalue/metalet helpers, it managed to flush out a lot of bugs in other features that use them.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1316723003 .
we already have to review them, so running a diff and failing the rest of the test pass seems unhelpful. Instead operate like our generated SDK does, and update in place
R=vsm@google.com
Review URL: https://codereview.chromium.org/1188173003.
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
essentially verify the expected HTML in the test
this tripped on an interesting issue, we have two ways of computing MD5 hashes that produce different answers. I left that as a TODO.
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1056613002
Now the HTML can include a hash in the URL for cachable resources, and the serve knows how to include cache-control headers.
In the process of doing so, I had to change a couple things that made it possible to fix#92 as well (producing different output in the command-line than in server mode).
R=vsm@google.com
Review URL: https://codereview.chromium.org/993213003
Moves: test/sdk --> tool/input_sdk_src
Also moves: test/sdk/lib/_internal/js_lib --> tool/input_sdk_patch
we'll eventually need to customize that code
Adds tool/patch_sdk.dart, an offline transformation step that produces: test/generated_sdk
Essentially this merges the "external" declarations and the @patch syntactically. There's a comment in tool/patch_sdk.dart explaining the rationale behind this approach.
There's still *lots* to do in the generated code. This does none of that. The only new code is tool/patch_sdk.dart and the minimum changes to test/codegen_test.dart and js_codegen.dart to get test.sh running and debuggable.
Tracking bug for SDK is https://github.com/dart-lang/dart-dev-compiler/issues/58R=sigmund@google.com, vsm@google.com
Review URL: https://chromereviews.googleplex.com/157137013
Vijay Menon