It relies on flutter copy of clang distribution, same one that is used to build flutter/engine.
It addressed several deprecated warnings from clang compiler for functions like strdup, unlink, etc.
It allows few warnings still since they are triggered in third_party sources.
Change-Id: Ieb13792c011438d46dbbc0fa030e1b5e4ea14315
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142704
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- Detect null safety when not specified before isolate
initialization
- for source files by having CFE parse the source file
for @dart annotations
- for kernel files by sniffing the kernel file for
compilation mode
- for appJIT files by sniffing the feature string
- for AOT snapshots by sniffing the feature string
- Remove workaround of returning null safety to false during
bootstrapping
- Add a new Dart C API call for detecting null safety
Bug: 41766
Change-Id: Ia8cf264323a2d0d58c2855ce6491456aa6f1da07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150089
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
server is started.
When the incremental compiler is used it accumulates state that
increases the footprint of the process. This state is needed only
when the 'reload' or 'expression evaluation' functionality is used
in the debugger.
Currently in the VM we do not have a good way of detecting when the
debugger will be used as the vm service observatory functionality
can be turned on dynamically after the program has started.
This CL turns on the incremental compiler only when command line options
are used to start the observatory server. We could run into issues with
'expression evaluation' when the observatory is started dynamically after
the program is loaded.
Change-Id: I18c17698622071bca428018f7fdac1a84b0f195e
Reviewed-on: https://dart-review.googlesource.com/64667
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Update status for simulators, which the test harness invokes with DIL files instead of source files.
Change-Id: I8444ad7e17a0a71a1ce3c0021487397baa1c3e65
Reviewed-on: https://dart-review.googlesource.com/54622
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
'--snapshot_kind=script --snapshot=xyz'
produce a kernel dill file which is the equivalent of a script
snapshot in Dart2 world.
Change-Id: I7ba66eb86d9ecdfe1426b8b22b8d673598c4b71f
Reviewed-on: https://dart-review.googlesource.com/52740
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change helps in confining flag manipulation to just the embedder.
When we are ready to turn all dart 2 flags to true by default, the
change can be confined to just the VM.
Change-Id: I4ac550c331b1f236a2bd9d0453b7c567eb0c05d3
Reviewed-on: https://dart-review.googlesource.com/38881
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
- Enabled incremental compiler in the dart frontend for the command-line VM
- Added method to update in-memory file system with in-memory sources provided by tests
Change-Id: Ica26b7235383185dbb6b4b41064193d432dfcba0
Reviewed-on: https://dart-review.googlesource.com/36126
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
The isolate creation callback flow was using DFE::kernel_file_specified()
to decide whether to load kernel program or not. However, since this flag
is not isolate specific, it was causing problems in the case where a dill
file was passed as the main dart program; the other isolates, even if
they were loading a snapshot, were looking for a kernel program.
This change was originally submitted as
"Make the decision, on whether to start the kernel isolate, liberal." It
was reverted due to failures on simdbc bots. This change is another
attempt which fixes those failures.
Change-Id: I096445faf470e77ab8f7cc810082891dcede5b60
Reviewed-on: https://dart-review.googlesource.com/36125
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 8986a85426.
Reason for revert: This broke our sim* builders, for example:
python tools/test.py -mdebug -c dartk -a simdbc64 service/next_through_assign_int_test
...
../../runtime/bin/main.cc: 202: error: expected: kernel_program != NULL
...
Unfortunately our sim* builders don't send out emails to authors because
they were setup with the new LUCI infrastructure. This causes failures
like this to not get noticed in time.
Change-Id: I759da4ce93817135cc5ffb6e1e6f374723e0e6d8
Reviewed-on: https://dart-review.googlesource.com/35927
Reviewed-by: Martin Kustermann <kustermann@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>
If a .dill file is specified on the VM command line (dart/dart_bootstrap),
and --kernel-binaries is not specified, then this dill file is used as
the source of platform libraries.
It supports the case of AOT-compiling a self-contained .dill file.
Change-Id: I42956a20b98958b9a2440f156fbbef17bfc359f8
Reviewed-on: https://dart-review.googlesource.com/24341
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The following problems are fixed in dart_bootstrap when it is used to
create AOT snapshot along with new kernel front-end:
* Data race between main isolate and service isolate when accessing
vmservice_io kernel program stored in DFE::kernel_vmservice_io_.
* Double-deletion of vmservice_io kernel file program from
VmService::LoadForGenPrecompiled / Dart_LoadLibrary /
LoadKernelProgram and then from DFE::~DFE.
It looks like both of these bugs were introduced in
c7faf2dc6b.
R=jensj@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/3002733002 .
This should cleanup user script kernel data and service isolate kernel data,
but leave the platform kernel data alone as it is used several times,
and it is unclear to me when it is safe to free it.
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/3000623002 .
This new flag value specifies the directory in which the VM should look
up the platform.dill file. A future change will require the VM to load
another kernel binary from disk. This binary will also live in the same
directory that --kernel-binaries specifies. This way, we avoid adding a
different flag for each of the different binaries.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2933203004 .
2. Read the platform dill file at startup not for every isolate creation
3. Store the memory representation of kernel program in isolate data so that it is deleted when the isolate is shutdown
R=aam@google.com
Review-Url: https://codereview.chromium.org/2927493002 .
asiva