This avoids conflicts with client repos that have a file
//build/compiled_action.gni with something different in them.
Change-Id: I133f66b0989bcb547cb8eed8710a88e2c1384bd7
Reviewed-on: https://dart-review.googlesource.com/53440
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change shifts logic for invoking Dart scripts during the build
from a couple of python scripts to a new template called dart_action().
Change-Id: Ic0818122cd7317cbd22a7255d880fe8f87271b7e
Reviewed-on: https://dart-review.googlesource.com/39260
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This linked in kernel service dill file will be used to load the kernel
isolate if the attempt to lookup the kernel service snapshot fails. The
kernel service snapshot is looked up in the following order.
1. If the "--dfe" option is specified, the file specified is used.
2. If the kernel service snapshot is found next to the executable,
then it is used.
3. If the kernel service snapshot is found in the "snapshots" directory
next to the executable, then it is used.
Change-Id: I5a0e757eb27b26a274b22b4bc36350fee59a100f
Reviewed-on: https://dart-review.googlesource.com/32446
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Chandra <sivachandra@google.com>
* kernel-service.dart is moved to pkg/vm/bin and renamed to
kernel_service.dart
* LICENSE, pubspec.yaml and analysis_options.yaml added to pkg/vm.
* Kernel isolate name is corrected to be independent of URI passed
in --dfe VM option.
Change-Id: I5b7b860297314e240e557af80913e7ac3e6324ad
Reviewed-on: https://dart-review.googlesource.com/21260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Setting this build argument to something other than host_toolchain will
cause the build target create_host_sdk to be exposed. That target will
build the Dart SDK with the toolchain specified by
dart_host_sdk_toolchain.
Relanding to fix bad toolchain conditions in dart_os_config and
dart_arch_config.
TO-549
Change-Id: I276f47d9071233acb98f6029a4666da0cee33d7d
Reviewed-on: https://dart-review.googlesource.com/18361
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This reverts commit 8fc90bd3bc.
Broken precomp bots due to wrong toolchain condition in dart_arch_config and dart_os_config.
Change-Id: Ic5c75f9ca3a0d4f316678354da44d1fcca10499d
Reviewed-on: https://dart-review.googlesource.com/18360
Reviewed-by: Zach Anderson <zra@google.com>
Setting this build argument to something other than host_toolchain will
cause the build target create_host_sdk to be exposed. That target will
build the Dart SDK with the toolchain specified by
dart_host_sdk_toolchain.
TO-549
Change-Id: Ida92521724cf7af34b34fb8c6d3514a226c48dd4
Reviewed-on: https://dart-review.googlesource.com/18145
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Change-Id: I6e6960c471b2fab3f0cd8a672da05d7699217410
Reviewed-on: https://dart-review.googlesource.com/12291
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: If5a1ea7082eae52e109f9b7272b2fcd0a866ba97
Reviewed-on: https://dart-review.googlesource.com/12000
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This separates compiling platform.dill files from the patch_sdk.dart
script. The motivation for that is that I'm working on reading patch
files directly from Fasta, so we can completely remove the build step
for generating patched_sdk and dart2js_patched_sdk.
Short-term this should allow Paul to add a strong-mode version of
platform.dill without causing to many conflicts with my work on
patches.
Change-Id: I1150845b2986348d4fffe27092701d8a9b57ea54
Reviewed-on: https://dart-review.googlesource.com/11506
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL replaces outdated VmTarget and FlutterTarget with VmFastaTarget
and FlutterFastaTarget. 'Fasta' suffix is droped from target names.
The new FlutterTarget extends VmTarget, so they share more code.
Change-Id: Id79956698a889c9a49b8a67914f1f96a731407ab
Reviewed-on: https://dart-review.googlesource.com/9423
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Previously the VM couldn't handle external libraries, but that was
fixed in 2f49198520.
Part of the CL was reverted though because the compilatin was changed
to using an outline instead of the platform which doesn't work.
What does work though, is not including the external libraries in the
output.
This CL makes the following changes:
* Don't include external libraries in the output (by not setting all
libraries to be non-external).
* Only writes the sources actually used to the binary (i.e. whatever
libraries left out because they were external will not contribute
source code either).
* Cleanup of now unused code.
Timings (only run once though):
Without this CL (but with the CL it's based on):
$ time python tools/test.py -m release -cdartk language -j6
Test configuration: dartk_vm_release_x64
[05:43 | 100% | + 3504 | - 0]
real 5m43.597s
user 33m48.152s
sys 9m34.140s
Only the "utils/kernel-service/kernel-service.dart" part of this CL:
$ time python tools/test.py -m release -cdartk language -j6
Test configuration: dartk_vm_release_x64
[04:55 | 100% | + 3504 | - 0]
real 4m55.684s
user 29m54.360s
sys 8m7.408s
Entire CL:
$ time python tools/test.py -m release -cdartk language -j6
Test configuration: dartk_vm_release_x64
[04:20 | 100% | + 3504 | - 0]
real 4m20.416s
user 27m17.320s
sys 6m53.472s
Change-Id: Ie9c5bfa958e558a5007784e821a0b58d417bae55
Reviewed-on: https://dart-review.googlesource.com/3161
Reviewed-by: Samir Jindel <sjindel@google.com>
2. Adjust the Dart front end to not require a 'main' method when the in memory filesystem is used, this allows execution of VM unit tests which all do not necessarily have a 'main' method (integrated CL from siggi)
3. Change kernel reader to not look for a 'main' methos when Dart_LoadKernel is called.
4. Change Dart_LoadScript to also support loading of dart programs when Dart front end is used
R=aam@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2948273002 .
Changes in this CL:
- Updated CompilerContext:
- it now contains a ProcessedOptions object
- it no longer depends on CompilerCommandLine/CommandLine
- it delegates to ProcessedOptions.report so all error reporting
goes to one single place.
- use "withContext" term instead of "withGlobalOptions" to be
more clear about the intent
- Changes in public API
- added more options that correspond to flags in command-line
fasta tools
- default onError is different: we now use the
command_line_reporting report, which prints and throws
on fatal messages, but doesn't throw eagerly on all messages
as before.
- introduced "printMessages" option: make it easy to have
both onError + command_line_reporting (kernel-service.dart
is the main use case at this time, other ideas welcome!)
- renamed CompilationError to CompilationMessage
- Other changes
- set exit code is done on report, not on format
- fixed corner cases not covered in previous CL
- error reporting with missing-main needs to happen with
a context
- missing error cases when inferring .packages and input
URIs are not file:* URIs
Ideas for follow up after this CL:
- combine ProcessedOptions and CompilerContext into a single class
(or extend one from the other)
- switch onError to a stream
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2982093003 .
to use the public frontend apis.)
* As part of the refactor I made kernel-service truncate the .dill file it
sends to the VM so it excludes the SDK code. This works in most cases, but
caused 26 failures in debug mode. The error matches what I saw in Issue
#30111.
* Some Dart2js tests using --use-sdk failed to run because they tried to find
platform.dill incorrectly. Our bots do have it available, we just have
to make sure to resolve it based on the build configuraiton and not based on
the SDK executable.
Review-Url: https://codereview.chromium.org/2974683003 .
Original CL had a bug that wasn't visible unless you delete your
out/ReleaseX64/patched_sdk folder.
Patchset #1 is the original CL, patchset #2 shows the fix.
This reverts commit 4aadfe09df.
BUG=
Review-Url: https://codereview.chromium.org/2976543002 .
This CL tweaks the public APIs in package:front_end, and
starts using those APIs outside the package. For example, this
removes 9 uses of DillTarget, so it is not longer mentioned
outside pkg/front_end and the analyzer_target.
Actual changes:
- in package:front_end
* added kernel_generator_impl: new file contains code that
used to be in kernel_generator. Code has some modifications:
it uses a single canonical-root when loading summaries, and
it supports generating both outlines and kernel in one go.
* removed code that didn't belong here:
a. most of calculating deps for .GN moved to patch_sdk
b. vm-specific outcomes moved to kernel-service
* updated how `native` is implemented, so we can more easily
support dart2js and ddc
* updated how we check where `int`, `bool`, etc can be implemented.
* added support "hermetic mode" in modular builds
('chaseDependencies = false' option)
* moved `trim` step out of fasta, and for now call it only within
the public API. This is not yet exposed, and I stopped covering it in
most tests (now only covered in shaker tests). The plan is to add
tests for the public API covering this in the future.
* removed `uriToSource` when serializing outlines
* added unit tests for public APIs
- patch_sdk
* use the public API to craete platform.dill, outline.dill (now
500K insted of 3Mb because it excludes sources), and vmservice_io.dill
* moved here logic internal to .GN
- kernel service
* use the public API
* moved here logic that depends on VM internals (e.g. status enum,
compilation results)
- package:compiler
* use the public API in tools and unit tests
* simplified patched-sdk generation: no more extending fasta's internals
- package:kernel
* fix bug in deserialization: initializers and other lists were
overwritten accidentally with external definitions.
* updated unit tests, moved shared logic to frontend/src/fasta/testing
R=johnniwinther@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2953703002 .
Allow kernel service request to provide source files(filename, content), which will be used to build up MemoryFileSystem instance. MemoryFileSystem instance will be used instead of PhysicalFileSystem instance.
Immediate need for this is to support VM unit testing, where small Dart scripts that have to be parsed are hardcoded in the unit tests.
BUG=https://github.com/dart-lang/sdk/issues/28264R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2880453005 .
Without this, we risk creating two different libraries at runtime. One
named file:///something/ and one named package:front_end/something.
These libraries are different and if enums from one gets mixed with
the other, you get very confusing errors (to apparently identical enums
aren't equal).
R=johnniwinther@google.com
Review-Url: https://codereview.chromium.org/2726793003 .
This adds a class CanonicalName that can represent a library, class,
or member. All references now go through a Reference object, which is
linked to both the AST node and its CanonicalName, so either can be
created first.
dartk now accepts multiple input files:
- If multiple dart files are given, they are all compiled.
- If multiple binaries are given, they are linked together.
Mixed dart and binary input is not supported by dartk.
dartk now has a flag --include-sdk which includes the entire SDK in
the output. This is so the SDK can be compiled alone and then linked.
Example of compiling separately and then linking:
dartk foo.dart -o foo.dill
dartk main.dart -o main.dill
dartk --include-sdk -o sdk.dill
dartk main.dill foo.dill sdk.dill --target=vm --link -o program.dill
dartk still has incredibly slow cold start due to the analyzer loading
the dart sdk, so this does not actually speed things up at the moment.
BUG=
R=ahe@google.com, kmillikin@google.com, kustermann@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2665723002 .
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 .
