The option is not used by any client at this time and removing it simplifies the
next stack of changes I'll be making on how we compose file systems.
I also don't believe we will necessarily add this back as an option, but instead
it might be that clients requriing hermeticity will provide a custom file system
that helps with that.
Change-Id: I401efb042920d234382b6c041b13d40ffae5c908
Reviewed-on: https://dart-review.googlesource.com/56462
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Most notably this fixes mixins, but a few others issues were discovered
as well. Fixes#32428.
This gets dartdevk closer to producing a valid Dart SDK file
Change-Id: I2973baef279d6b71ed29b97bec758b2d3209c275
Reviewed-on: https://dart-review.googlesource.com/51760
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This works around broken FunctionTypeImpl.== in Analyzer. Also
makes DDK's type naming heuristic more consistent with DDC.
Change-Id: I09527fad681c3fdc6c66654e572e9b03c57491bd
Reviewed-on: https://dart-review.googlesource.com/37120
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Also adds this to the build script, so we can eventually replace the existing SDK compile step with this new one.
Change-Id: Iba0720df5bbab302d2fdd0b5aeeb182de152cc98
Reviewed-on: https://dart-review.googlesource.com/32504
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This CL deprecates the front-end API and moves it into src/api_prototype.
For now all usages have been updated to point to the new location,
but they should be updated to use custom-client invocations instead (e.g.
one specific way for DDC, another for dart2js etc.)
Bug:
Change-Id: I9b4f41f6ebf55d42510fd35240d942d1dc7292d6
Reviewed-on: https://dart-review.googlesource.com/24822
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This CL adds the bare minimum of source map generation for the kernel
pipeline in DDC.
It additionally introduces a testing framework that compiles dart files
with DDC (with or without kernel), steps through it via D8 and compares
the positions stopped at to the expected stop positions.
Bug:
Change-Id: Ie9e06164d8e51c973b83c46a8472e044876e4317
Reviewed-on: https://dart-review.googlesource.com/20662
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This allows dartdevk to compile tests that import packages like expect.
There are a few pieces to this:
- Add support to build_pkgs.dart to build the kernel summaries for each
test package (in addition to the analyzer summaries it already
builds).
- Plumb that through the dartdevc_test target in the GN build as well.
- While we're at it, use GN to build the ddc_sdk.dill file and have
test.dart load that one instead of the manually built one from calling
./tool/kernel_sdk.dart.
- Add command-line arguments to dartdevk for passing in the path to the
SDK summary and the other summaries to compile against.
- Fix a little typo in processed_options.dart that was preventing it
from resolving "package:" URIs.
- In test.dart, when compiling a test, link in the summaries for all of
the test packages.
At runtime, it still uses the JS for those packages generated from the
old analyzer-based front end since the kernel-based compiler isn't
complete enough to compile any of those packages yet.
With all of this, if I change a test to:
import "package:expect/expect.dart";
main() {
Expect.equals("a", "b");
}
Then it compiles but fails at runtime. The compiler is completing, but
the generated code has some bugs. I don't know enough to fix them
myself, but here's what I've found out:
- In _libraryToModule(), the Library we get from kernel has a null
fileUri, so this returns an empty string. That in turn means the
generated JS tries to use "$" as the module name.
Using this works around it temporarily:
if (moduleName.isEmpty) moduleName = library.name;
- In _emitTopLevelNameNoInterop(), it doesn't handle the case where the
NamedNode is a static method on a class. It just generates the library
and method name, skipping the class, so "Expect.equals(1, 2)" gets
compiled to "expect.equals(1, 2)" instead of
"expect.Expect.equals(1, 2)".
Change-Id: I6bd9d98bc9706965160d8fb7cf70b20eeebab3a8
Reviewed-on: https://dart-review.googlesource.com/16687
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This ports a fairly large part of DDC's Analyzer-based code generator,
however most nodes are not supported yet.
The goal is to preserve all functionality of code that was ported,
except for deprecated features (e.g. mirrors, fuzzy arrows, libraryRoot).
Change-Id: I3b10d5773c7c10a740fa336720243b03c6b82529
Reviewed-on: https://dart-review.googlesource.com/10705
Reviewed-by: Vijay Menon <vsm@google.com>
Sigmund Cherem