Types should have never been used here in the first place.
And with nullability we get mismatches where type parameters are used
with a suffix :-(
Change-Id: I93ff61ee9bf32c24cdf3d2aadeb23cbb84b34cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124501
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is to reduce load on Android benchmarking hardware.
Change-Id: Ib51b3fbbe2bf66cb0ba17375062a747f37284299
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124600
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
A core assumption of the migration tool is that the code being
migrated may have some dependencies that have already been migrated
(e.g. the SDK itself). Of course these dependencies will need to be
analyzed as "opted in" libraries so that they can have nullability
annotations.
However, when the migration tool was first being developed, we didn't
yet have a migrated SDK, so the SDK was opted out and we just had to
pretend that it was opted in.
This CL prepares to switch over to a truly opted-in SDK by updating
the AlreadyMigratedCodeDecorator to handle opted-in code.
Change-Id: I797752401f8c7bf7cdf8d26d03d00d3d213a5127
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124466
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only optional parameter that was actually used was
nullabilitySuffix, so eliminate the others, and make it a named
parameter for easier future expansion.
Change-Id: Iee05e955a1c996b4e1dd9bbec3db7fd1588ebe04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124001
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, when the code being migrated referred to a nullable or a
non-nullable type in an already-migrated library, we would use the
`always` or `never` graph node to represent the nullability of the
type. This was problematic, because it made it difficult for
instrumentation to pinpoint precisely which element in an
already-migrated library was the cause of an expresion being
null-checked, or a type being made non-nullable.
We now create a fresh nullability node for each non-nullable type
coming from already-migrated code, with an edge to `always` or `never`
to ensure that the fresh node has the correct nullability, so that
instrumentation can see precisely which element it came from.
Since the migration tool doesn't traverse the ASTs of already-migrated
code, we can't report an AST node that caused such an edge, so an
`element` getter has been added EdgeOriginInfo to allow us to report
the element that caused the edge.
As before, types associated with already-migrated code are reported to
instrumentation via InstrumentationListener.externalDecoratedType. As
a new enhancement, bounds of generic parameters in already-migrated
code are reported to instrumentation via
InstrumentationListener.externalDecoratedTypeParameterBound.
Change-Id: Ided4e96e2920f8d9062688f5a6fda29b9b71dd12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124000
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
This change allows to run test.dart and pkg/test_runner with multiple arguments
for the -n option to run tests for multiple configurations with one invocation.
Change-Id: If62e0bfc364460fa415c7f700f7e449b0de56987
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122395
Commit-Queue: Karl Klose <karlklose@google.com>
Reviewed-by: William Hesse <whesse@google.com>
This is needed for the next D27 release.
Change-Id: I199ac701cb140dc84bb723d232c1b408088b1fe2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124469
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
We now print the error code as well as the message, which makes it
easier to locate the analyzer code related to the error.
Change-Id: I9e18744ce8e58efe6a5ecb7e7a98035777982836
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124381
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The proper behavior of null-shorting relies on proper pairing between
FlowAnalysis.nullAwareAccess_rightBegin (called upon reaching a `?.`
during resolution) and FlowAnalysis.nullAwareAccess_end (called upon
reaching the termiation of null-shorting during resolution).
Previously, we ensured that invariant by the following mechanism: when
visiting an expression that might terminate null-shorting, we would
walk backward through the expression to try to figure out how many
outstanding `?.`s it contains, and call
FlowAnalysis.nullAwareAccess_end an appropriate number of times. This
was fragile because we had to guarantee that the backward walk would
find exactly the correct set of `?.`s for which null-shorting was
open.
With this change, we ensure proper pairing between
FlowAnalysis.nullAwareAccess_rightBegin and
FlowAnalysis.nullAwareAccess_end by keeping a stack of the expressions
that should terminate null-shorting once we finish visiting them.
Additionally, we add an accessor to the API called
`nullShortingTermination`, allowing a client to ask when the null
shorting introduced by a `?.` will terminate.
Change-Id: I8ec99e6bad7605d50ef3a6bc6c11634ece5043a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
specialization.
This change also adds plumbing so that we can access the kernel logic
for instantiation-to-bounds. This allows us to emit the `instanceof`
is-test specialization when all type arguments are at bounds.
Change-Id: I73cdcaeb1984d31761ddb9a5765e5bd0f29d06ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124206
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This change will optimize code generation for contravariant checks on
variantly sound type parameters. We avoid emitting `_check()`s.
This will also add the change to ensure that reified types of torn off
methods are correct.
Change-Id: Ic7a4aa8f92b5e3489f7cd590070772358ef2c84b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124108
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Most types in opted-out libraries should be legacy (with few exceptions,
such as Null or dynamic). All types in opted-in libraries should not be
legacy.
Change-Id: Ib595eeae0e76cdbf53ffd92313d429d8381f9786
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124320
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Remove the switch; create a acceptInference implemented by all the
InternalExpressions instead.
Change-Id: Ib58362fee88e5dde8f1331b51e9eece209936f6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124321
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Add a flag to the verifier that tells it to assume that full constant
evaluation has been performed. It will then complain about anything
that should not be there after constant evaluation.
Also fix two bugs exposed by the new checks:
- The constant transformer did not visit annotations on type parameters
in function nodes.
- The InstanceCreation constructor did not set the parent pointers of
its children.
Change-Id: Ieef865a51892918e524da973b0cbaf52ed467181
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Add checks that --aot cannot be used with the following options:
--no-link-platform (front-end server, gen_kernel and Fuchsia kernel compiler).
--split-output-by-packages (front-end server, gen_kernel and Fuchsia kernel compiler).
--incremental (front-end server).
--import-dill (front-end server).
Change-Id: I0a38ab8b3a31ec497d1dc05ace0c254455879504
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123820
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This saves one byte per Type and per TypeParameter objects in the snapshot.
Change-Id: Ie5241c992a5c5cc6b3d7a211f20e7a0ddbd00b72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124300
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This unblocks changing this logic for NNBD since they are now forked.
The custom logic for FutureOr has been problematic to represent in the patch
files. They need to be callable from the class but they can't be static methods
in Dart because they reference the generic type argument. It is a design quirk
of the runtime representation that the type argument is captured in the wrapping
closure and in scope that allows the existing implementation to work.
In a future change I will thread an NNBD flag through the compiler to emit
different logic for the FutureOr type tests when running with NNBD.
Change-Id: I9463e3cd375f8098592ea84e956e833952f41bb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123921
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
I'm not sure where the test for this should go. I found it while
migrating vector_math.dart.
Change-Id: I0c1c5ba91375b2a36540f4c270cef6dc9558a745
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124103
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
