We are not switching yet, but now everybody can try fasta by doing:
$ dart -DDFE_USE_FASTA=true --dfe=utils/kernel-service.dart hello.dart
Note that when using fasta we expect that patched_sdk contains platform.dill
Kernel binary containing compiled patched sdk. This file can be obtained by
doing:
$ export DART_AOT_SDK=<path-to-patched_sdk>
$ dart pkg/front_end/lib/src/fasta/bin/compile_platform.dart \
${DART_AOT_SDK}/platform.dill
We are also adding --use-fasta to testing script to allow end-to-end testing
of fasta (though platform.dill file needs to be generated manually prior to
running tests):
$ tools/test.py -c dartk -m release -a x64 --nobatch --use-fasta
Current test status:
$ tools/test.py -c dartk -m release -a x64 --nobatch --use-fasta
[27:34 | 100% | +12566 | - 1941]
BUG=
R=ahe@google.com, kustermann@google.com
Review-Url: https://codereview.chromium.org/2684943003 .
Target-specific modular transformations have to be able to cope with
external libraries. Target-specific global transformations should be
optimizations, and not required for correctness, since a simple linker
may choose not to perform them.
Make mixin resolution modular by making it fail when a mixed-in class
comes from an external library. (We cannot mix in such a class because
we do not necessarily have all class members.)
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2671653003 .
- Don't mark core_isolate_snapshot_buffer as a const pointer.
- Update app snapshots without code to not rewrite the VM isolate snapshot, as already done by app snapshots with code.
Fixes#28368R=asiva@google.com
Review-Url: https://codereview.chromium.org/2637193002 .
This makes doing an SDK build in the Fuchsia tree easier.
The previous attempt at this change failed in gyp builds targeting xcode.
They failed because input lists for actions of the same target (e.g. the
actions for dartanalyzer) are merged and de-duped when the lists contain
relative paths, but merged and *not* de-duped when the lists contain
absolute paths. gyp rejects xcode files that it generated itself
when they contain duplicate entries.
This CL works around that bug, by using absolute paths in the GN build
and keeping relative paths in the gyp build.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2567213002 .
GN is unhappy when a rule that consumes a file generated by
another rule doesn't depend directly on that rule.
This change also quiets output from invoking Dart to follow the
rule of GN builds that a successful build generates no output.
Review URL: https://codereview.chromium.org/2446473002 .
Also update DEPS to bring the latest dev_compiler into the SDK.
This is a second attempt at
https://codereview.chromium.org/1777173003, with the following fixes:
- Added .bat files for Windows.
- Added missing dependency: create_sdk_internal depends on
dartdevc.dart.snapshot.
- Used pkg_files.stamp to note the source code dependency for
dartdevc, so that we don't go beyond xcodebuild's input length
limit.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1818543002 .
Paul thinks that there is a bug in gyp or make, and we should generate
only one output. So, we generate the whole bundle with all summaries
and index information. And then we have separate actions that take
this bundle and extract one output each - spec.sum and strong.sum files.
R=paulberry@google.com, whesse@google.com
BUG=
Review URL: https://codereview.chromium.org/1775973003 .
We cannot commit this CL right now, because we will attempt to use
these summaries by default, and they are incomplete yet. But I wanted
to see how to add something to the build process, and we might do
changes to make using SDK summaries optional initiallyand then commit
this CL.
R=paulberry@google.com, whesse@google.com
BUG=
Review URL: https://codereview.chromium.org/1588093005 .
Peter von der Ahé