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>
This is no longer necessary with the VM only supporting the latest
version and kernel (optionally) including a git-checksum to match up
VM and dills.
Change-Id: Ifccfd0d12333cd99258100cda30e1536cc230bc2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166024
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL:
* adds a test that runs the VM with old dills (compilations of dart2js
with old checkouts) with the --compile_all argument (1).
* adds a number of old dills (for binary version 25, 27, 28, 29)
(by mistake binary version 26 sort of didn't really happen)
* adds a PRESUBMIT check in kernel that verifies that we have an
"old dill" for the current binary version, so one don't bump the
version without creating a new dill.
(1): It uses --compile_all to force the VM to "read and understand"
everything in the dill file. The hope being that we try out
all/most language constructs and thus verifies that they can be
read by the VM.
Old "old dill" files should be removed once the VM stops supporting that
version. That is a manual process, but a test should complain that the VM
cannot read the old "old dill"(s) once/if that happens.
This should (help) detect errors such as the one recently where a merge
error caused a single "if >= 28" (that should have been "if >= 29" and
thus stopped the VM from reading dills from version 28) to slip through
and require a lot of debugging a few days later.
Change-Id: Id79e16c7ad896c0ccc4e181465b05b67822ac31a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113698
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
"bin" is part of the public API of a package, private tools can go under the
`tool` folder. This allows us to use a dev_dependency on analyzer without
exposing a broken import publicly.
I've only moved `dartk` so far (which I expect will be removed once we have a
better API for front_end.
R=asgerf@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2842643002 .
Lasse R.H. Nielsen