When trying to invalidate files when using a multi-
root file system, if a .dill file that is being
used to initialize an incremental compiler contains
both files with a custom marker scheme, as well as
an internal one like `org-dartlang-sdk`, it will
throw when it encounters the internal scheme.
This commit remedies the issue, but this is my
first CL to the SDK, I'm not sure if this is
the best approach.
Other approaches may be:
- Ignore dartlang internal file schemes only
- Catch errors from entity.exists instead of filtering
And I'm sure there are many others.
Change-Id: Idc7aba4b41eb5cf7f66db492f0ea6e26252779c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/94680
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
For initializeFromComponent to work correctly the platform has to be
provided (as the other libraries provided are linked to some platform,
and loading another one is thus no good).
This CL changes it so we don't load another one, and checks that the
component we're trying to initialize from actually contains dart:core.
Change-Id: I88d30436c101c589b0555ff70ae21297ed665d7b
Reviewed-on: https://dart-review.googlesource.com/c/93435
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This includes:
* Selecting front-end target.
* Support for multi-root virtual file system.
* Not linking platform into resulting kernel file.
* Specifying input as URI (instead of file path) on command line.
* Automatically converting input script URI to package URI.
* Writing ninja dependencies file.
* Writing package-split kernel binaries.
After this change Fuchsia's compiler.dart will become a small wrapper
over pkg/vm, sharing most logic and even most command line options
with pkg/vm gen_kernel tool.
Also, this CL attempts to share some pieces of code between frontend
server and gen_kernel.
In addition, seperate bytecode generation for package-split binaries
is implemented (needed for https://dart-review.googlesource.com/c/sdk/+/85469).
Corresponding Fuchsia CL: https://fuchsia-review.googlesource.com/c/topaz/+/229964
Change-Id: I12d7b2f6401357b3c9df2e31bc736af5a9dc5fd2
Reviewed-on: https://dart-review.googlesource.com/c/85721
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
'package:'-scheme uris are important with compiler enforcing unique identification of files present in packages(that can be referenced either via 'package:'-uri or via 'file:'-uri).
Change-Id: Ib3006dadbdd1dfc5fe1df800cae3f95bcbb37063
Reviewed-on: https://dart-review.googlesource.com/c/80361
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
--unsafe-package-serialization saves the frontend_server from having to
re-serialize everything all the time.
Before this CL, though, things could go wrong:
If you had a situation where you had previously compiled a file that
depend on a package A, and where (some of) package A depends on
package B this would happen:
- All of package A was serialized together.
- All of package B was serialized together.
When later, you compile something that depend less on package A - namely
on only on parts that does not depend on package B, but is included in
the previously serialized package A, the following would happen:
- The new (non-package) libraries would be serialized.
- Package A serialization would be reused.
This is basically fine: Running the app would be fine, everything it
actually depend on is there.
However, if the VM is forced to compile everything it now also compiles
stuff that was included - but really unused - from package A - namely
also the libraries that depend on package B --- which is not included.
This CL changes the last part by also including package B.
The result is that even more unused libraries are included, but that
the VM can survive a forceful compile.
Note that the --unsafe-package-serialization is only used for tests,
so the "including even more unused" part is probably not a big deal,
and all in all there's still a big speed advantage to doing this.
Change-Id: Iac06ba6f40c2caaacce641c5853e9491496dce53
Reviewed-on: https://dart-review.googlesource.com/c/78541
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Also, convert package:vm to use onDiagnostic.
We're consolidating all dependencies on package:front_end in one file per tool.
The idea is, if you want to depend on something in the package:front_end, you modify pkg/front_end/lib/src/api_unstable/vm.dart and consult with the front-end team.
These consolidated files will help us when designing a public API in the future.
Change-Id: I66bafdd0ae29605fd12f8d6c589dbc761e5c7a97
Reviewed-on: https://dart-review.googlesource.com/c/77581
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
This CL introduces an option - unsafe-package-serialization - where a
caller can select to reuse the serialization of packages. This makes it
unsafe in general, but if never invalidating packages, such as in tests,
it can be used to greatly increase the speed of processing many inputs.
This change - used in flutter - takes the time it takes to run
`flutter test` in `packages/flutter` from ~2 minutes 30 seconds to
~1 minute 15 seconds (on my machine).
A change to how flutter test executes the frontend_server
(to pass the option) is needed for it to take effect though.
Change-Id: Ibe47b43c41286eb08f80c9e7a398e1dc67bf9bc0
Reviewed-on: https://dart-review.googlesource.com/48200
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
frontend_server uses getTarget - which means we need to call
installAdditionalTargets to ensure that flutter & vm targets are
properly installed.
Change-Id: I00a3d06f76c3bd31fe4e27e3947abea4c7883c44
Reviewed-on: https://dart-review.googlesource.com/69464
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
With explicit exit() invocation, frontend_server_test only gets through first two tests before exiting.
Change-Id: Ica0b6f4f09baa8262b6097779be772877ca6f8d8
Reviewed-on: https://dart-review.googlesource.com/69220
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Do not start the kernel isolate from an app-jit snapshot when
creating app-jit snapshots as this causes build issues.
Change-Id: Id9e48526ab85cfc90aed030e492c432ebb32caef
Reviewed-on: https://dart-review.googlesource.com/65792
Reviewed-by: Siva Annamalai <asiva@google.com>
When invalidating changed files in frontend server, the state prior to
this CL was that a continue would jump to the next byte, not the next file
after it had seen that the file had changed. Thus it could possibly
invalidate the same file several times.
Change-Id: If6fb1042248d26a3ffe905b39fa3c3603198ca37
Reviewed-on: https://dart-review.googlesource.com/60245
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The `@pragma` annotation on `vmservice_io.main` is modified to only mark it as a
root on non-product builds. Since the annotation is evaluated in the constant
transformation, we need to thread a flag through `gen_kernel.dart` indicating
whether the Kernel produced should target a product precompiler.
# Test Plan
Tested locally on Flutter. Unfortunately it's not possible to test the scenario where
`vmservice_io` is not included, since we don't have any "product" bots. Soon the
flag will be introduced into Flutter, and we will have some coverage from there.
Change-Id: I39f12343038fa221aafe5a55241bff4b8d14ec19
Reviewed-on: https://dart-review.googlesource.com/57501
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL updates the frontend_server to allow specifying what dill
file to initialize from.
Normally, it tries to initialize from the same dill file as is the
output. This is fine in many cases (e.g. flutter run always says it
should output to build/app.dill): The first time it compiles
everything, subsequent times (across restarts) it only recompiles
what's needed.
When running tests, however, the output is in a temporary directory,
so it doesn't work across restarts. The startup time for tests is
always rather high, because it always has to recompile everything.
This CL updates the frontend_server to allow specifying what dill
file to initialize from. Flutter can thus save the compiled test
file in a centralized location (e.g. build/test.dill) and load from
that across restarts.
Plumbing this into flutter yields the following result, when running
a single test (the one automatically created when creating a new
flutter project):
Before: ~5.5 seconds
Now, first run: ~5.5 second (unchanged)
Now, subsequent runs: ~3.4 seconds
Approximate breakdown:
Startup cost (e.g. if there's no test directory): ~ 800 ms
Starting up the actual frontend server: ~150 ms
Reading source from old dill, loading all relevant files
and invalidating source: ~ 300 ms
Compiling everything (or, rather, nothing as it's all
from the dill at this point): ~ 650 ms
Serializing: ~ 250 ms
Copying files: ~ 50 ms
Running the actual test: ~1100 ms
Total: ~3300 ms
`time flutter test --local-engine=host_debug --preview-dart-2`
says ~3.4 seconds...
To compare, --no-preview-dart-2 takes ~2.2 seconds,
so dart2 still has a (significantly) higher startup cost.
Moves the needle on https://github.com/flutter/flutter/issues/15767.
Change-Id: I36a2d05bc76e0193d369df42eb3b9f08416dd78f
Reviewed-on: https://dart-review.googlesource.com/51820
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Second try. First try was reverted because a previously empty URL (the
default 'always there' one) is now a null url instead, which wasn't
handled properly in the frontend_server.
See 47e9039512 for original details.
This reverts commit 4c9b712052.
Change-Id: I717eb927cbe29b6388e72f7e270428d234d44e4d
Reviewed-on: https://dart-review.googlesource.com/53580
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This change adds experimental option '--import-dill' to front-end server
to specify existing kernel file to import when compiling a new one.
Newly generated kernel file will depend on the imported one and will
omit libraries available in the imported dill file, as well as platform
libraries.
Caveat: the new option is not compatible with '--incremental'.
Change-Id: Id637908afdb12f1829e5f634251fa9ad82676baf
Reviewed-on: https://dart-review.googlesource.com/54309
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This allows frontend-server users(flutter) to do quick check whether frontend compilation reported errors as it produced output kernel file.
Change-Id: I6e4da8fac33104968eb7720200a1b7153ec8f3de
Reviewed-on: https://dart-review.googlesource.com/51000
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Jacob Richman