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>
This should make it possible to run compile_platform_test.dart inside
google3, where package layout conventions are more strictly enforced
(files in test/ cannot import files in tool/).
Change-Id: I2299e0340b0edfc1a684a635de8cf87ecb9f241f
Reviewed-on: https://dart-review.googlesource.com/8701
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before: ownership of some or all of the libraries from one Kernel
program (P1) would be transferred to another program (P2). All the
canonical names in P1 would be unbound from their references and the
canonical names would eventually be recreated for the libraries that
were transferred.
After: when ownership of a library is transferred, the ownership of
the canonical name subtree rooted at the library's name is also
transferred. This allows the 1:1 relationship between Canonicalname
and Reference to be maintained which will enable lazy deserialization
of procedure bodies (because the mapping from CanonicalNames to
References in the corresponding link table will be persistent).
Change-Id: I98f975d6ba5804f975c30528a484756b39f09d2a
Reviewed-on: https://dart-review.googlesource.com/7549
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>