This adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Currently Dart SDK has 2 platform dill files:
* vm_platform_strong.dill is used when compiling Dart sources (in kernel
service and various kernel compilers).
* vm_platform_strong_stripped.dill is used to build core snapshot,
so its contents is used for execution in the VM.
Before this change, if Dart SDK is built with bytecode, then both
vm_platform_strong.dill and vm_platform_strong_stripped.dill contain
bytecode and AST.
This change removes bytecode from vm_platform_strong.dill, and removes
AST from vm_platform_strong_stripped.dill.
Sizes:
Dart SDK is built without bytecode:
5861400 out/ReleaseX64/vm_platform_strong.dill
2819336 out/ReleaseX64/vm_platform_strong_stripped.dill
32105720 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, before this change:
11146480 out/ReleaseX64/vm_platform_strong.dill
4846488 out/ReleaseX64/vm_platform_strong_stripped.dill
34219256 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, after this change:
5861400 out/ReleaseX64/vm_platform_strong.dill
2027224 out/ReleaseX64/vm_platform_strong_stripped.dill
28382456 out/ReleaseX64/dart-sdk/bin/dart
Change-Id: Ia7c61a9bce1c95edfd3b2810a67c0964fb37377f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118371
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
That should allow us to "implement"
6f85cb83cf again in two steps:
* first we remove the dart:profiler as a required library, but retain it in the platform
* (we wait for stuff to roll, both in flutter and in google3)
* we remove it completely (i.e. not retaining it in the platform, removing the source etc)
Change-Id: Ieb77c2ba909300c05f3923c2edba7cab7d34fae6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115244
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* Include source positions, source text (if provided by front-end, which is
controlled by a separate option) and assertions into platform with bytecode.
Also use environment defines if provided.
* Omit bytecode for synthetic static fields '_redirecting#' injected
by front-end, as they contain invalid AST nodes (taking tear-off of
a constructor). This is needed to avoid emitting bytecode which cannot be
loaded.
* Correctly merge source information such as source text and line numbers
in bytecode generator if the script was originally created for an
anonymous mixin application without such information.
* Always include import URIs into source information, even if other information is
excluded (for members in anonymous mixin applications / noSuchMethod forwarders /
forwarding stubs).
* Set native resolvers for vm/cc/PrintJSON test, as printing all objects to JSON
involves collecting token positions, which may read bytecode from platform and
need native resolvers to process native method entries.
Change-Id: I971e880c25439c0ec69db3a231a0085ccd5d15ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113780
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Change all the places that still used old-style asynchronous async in
Fasta. These were mostly in testing.
Change-Id: I102209aa54c7c6e658b9d6ec98167af62bf12f3e
Reviewed-on: https://dart-review.googlesource.com/c/87074
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
In Kernel's TargetFlags, this flag still defaulted to false. Flip the
default to true and update all client code in the SDK. The
expectation is that many of the places that now pass false explicitly
really just want the default, but that will be verified separately and
then the flag will be removed.
Change-Id: I2a38eb53f280f21f59bb1d2e88c42516f827fd39
Reviewed-on: https://dart-review.googlesource.com/c/85448
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Previously we had several places where different uriToSource was used.
This was both weird and led to errors when something refering to
some state was used to look up in another state.
This CL makes it so we only have one source of truth.
To not include sdk sources when serializing a component that only mixes
something from the sdk in, (or extends it or...), the serialization is
changed slightly to keep track of which uris come from actual
implementation. Before the sdk sources was explicitly removed in the
incremental compiler, but we want to limit those kinds of things,
which is why we're doing it differently here.
Fixes#35215.
Bug: 35215
Change-Id: Iaa5618fcb0ea42b13aba7720f34a87a85144e047
Reviewed-on: https://dart-review.googlesource.com/c/85175
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
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>
This is a step towards removing the option --strong-mode because
it's supposed to be on by default.
Change-Id: I25da0038d12e359f9c628beb2f92293295f00185
Reviewed-on: https://dart-review.googlesource.com/39983
Reviewed-by: Jens Johansen <jensj@google.com>
Jens Johansen