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>
This includes Fasta, tools and observatory, so the checked-in SDK must
have the lower-case constants.
Change-Id: I8380ad041ad058f7d02ae19caccfecd434d13d75
Reviewed-on: https://dart-review.googlesource.com/50201
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Change-Id: I7ab8e989e1e2038565e1d04a1c8f8ce880328ed8
Reviewed-on: https://dart-review.googlesource.com/47500
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Change-Id: I1a3cc03fba9783807fa637a9d42fdbad68ee7686
Reviewed-on: https://dart-review.googlesource.com/31040
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
- Load vmservice_io library only in the service isolate or when an AOT snapshot is being generated
This should account for the following issues:
- https://github.com/dart-lang/sdk/issues/31203 - there should be a vmservice_io_strong.dill file
- https://github.com/dart-lang/sdk/issues/30158 - Consider extracting flutter vmservice_sky into
separate .dill from platform.dill
- https://github.com/dart-lang/sdk/issues/30111 - support compiling vmservice with an external
outline of the sdk
Bug:
Change-Id: If945ec05afe8127e288e8d3b55172c0f7c3d6e7a
Reviewed-on: https://dart-review.googlesource.com/18147
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Siva Chandra <sivachandra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Change-Id: I4713ba8aafa5f7119bbdb2b26746f2fff50042a6
Reviewed-on: https://dart-review.googlesource.com/12284
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The Flutter engine will soon be mapped to //third_party/flutter in Fuchsia.
Change-Id: I280e2ffcfc3de2a5c7ffb96159d7d37341a974a3
Bug:
Reviewed-on: https://dart-review.googlesource.com/13601
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Fixes#31034.
Change-Id: Ifb9ed97fe8cddb317cb63e7d66f262ef9e68ee75
Reviewed-on: https://dart-review.googlesource.com/12282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Peter von der Ahé <ahe@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>
This CL:
* introduces the Dart API to operate over libraries specifications and describes
the format we intend to use (see libraries_spec.dart)
* implements serialization/deserialization for this API
* switches over the front_end to use these APIs
* public options accept a URI to the JSON file and no longer
accept a `dartLibraries` map
* internal code uses the LibrariesSpecification API
* switches other dependencies on these APIs (resynthesizer_test and patch_sdk.dart)
This is the first step in migrating over to use the libraries.json format and
eventually remove the patched_sdk step. In particular, some of the next steps
include:
* add a build step to generate .json files from .yaml files
* add a libraries.yaml file for the sdk
* split the patched_sdk step in two:
* patching files
* generating .dill files
* add any missing support for patch-files in fasta
* finally remove the patching files step, and only have a build step for generating
.dill files
BUG=
R=ahe@google.com, paulberry@google.com, scheglov@google.com
Committed: abf2d23af2
Review-Url: https://codereview.chromium.org/2986303003 .
This reverts commit abf2d23af2.
Reason for revert:
- win build failed in patched_sdk (likely storing paths and not uris)
- dart2js bots failed (missing flag)
Will fix the issues and reland shortly.
Review-Url: https://codereview.chromium.org/2993113003 .
This CL:
* introduces the Dart API to operate over libraries specifications and describes
the format we intend to use (see libraries_spec.dart)
* implements serialization/deserialization for this API
* switches over the front_end to use these APIs
* public options accept a URI to the JSON file and no longer
accept a `dartLibraries` map
* internal code uses the LibrariesSpecification API
* switches other dependencies on these APIs (resynthesizer_test and patch_sdk.dart)
This is the first step in migrating over to use the libraries.json format and
eventually remove the patched_sdk step. In particular, some of the next steps
include:
* add a build step to generate .json files from .yaml files
* add a libraries.yaml file for the sdk
* split the patched_sdk step in two:
* patching files
* generating .dill files
* add any missing support for patch-files in fasta
* finally remove the patching files step, and only have a build step for generating
.dill files
BUG=
R=ahe@google.com, paulberry@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2986303003 .
Flutter non-release should have vm_service package included into platform.dill to handle observatory requests, while release builds should not have it as they are not supposed to have observatory functionality enabled.
R=ahe@google.com, sigmund@google.com
BUG:dartbug.com/30112
Review-Url: https://codereview.chromium.org/2972323002 .
Turns out the args were swapped, so we were writing one of our output files with the contents of the deps file. Later the script overrode that output file, so we didn't notice it.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2980873003 .
There were a couple issues found in the bots:
- dart2js unit tests I accidentally missed earlier.
- vmservice issues only show up in the debug-vm, I was testing locally with the
release vm.
- a small regression in detecting invalid .packages files. I marked the test
failing for now and plan to follow up on this on Monday.
TBR=ahe@google.com,paulberry@google.com
Review-Url: https://codereview.chromium.org/2974703002 .
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 .
This directory has a libraries.json file pointing to vmservice_io and
_vmservice in the source tree. The script tools/patch_sdk.dart has been
updated to use this new directory as the sdk directory when compiling
dart:vmservice_io. This way, to build vmservice_io.dill, we
do not need to copy the dart files pertaining to vmservice_io and
_vmservice.
Fixes#29859R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2938903003 .
- defines a .gn target for patched_dart2js_sdk
- changes patch_sdk.dart to handle a dart2js target
- adds support in fasta to understand the `native` clause still used by dart2js
- add option to fasta to know whether it is generating kernel for the vm or dart2js
I'm not excited about how I added the target distinction in fasta, the reason I
did so is that it affects the behavior in several ways: in how we handle
`native`, in the libraries that are included by default in the platform.dill file,
and in the transformations that need to be done. I'm happy to change the
approach.
BUG=
R=ahe@google.com, vegorov@google.com, zra@google.com
Committed: 714523b103
Review-Url: https://codereview.chromium.org/2832353002 .
