This logic allows us to migrate code like this:
int firstEven(Iterable<int> values)
=> values.firstWhere((i) => i.isEven, orElse: () => null);
Into:
import 'package:collection/collection.dart' show IterableExtension;
int? firstEven(Iterable<int> values)
=> values.firstWhereOrNull((i) => i.isEven);
Rather than the default behavior, which would migrate it to:
int? firsteven(Iterable<int?> values)
=> values.firstWhere((i) => i!.isEven, orElse: () => null);
(The new migration is far superior because it doesn't require the
input iterable to accept null).
This functionality is disabled at the moment, because:
- The changes it makes don't show up properly in the web preview.
- The pubspec is not yet properly updated.
I will address these issues in follow-up CLs and then enable the
feature.
Change-Id: I96f3b12d682c586631920b38406bad6aa3f4789e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168500
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/38291
This change also involves moving the "package" where test sources are
written and analyzed; It used to be /home/test (or /project in some
places); and a pubspec.yaml was written (or a .packages file) which
specified the package's name was "test". However, this conflicts with
adding an entry for a mock copy of the actual _test_ package. A
.packages file cannot have two entries for a package named "test", so
the package where all test sources are written is changed to "tests"
(located at /home/tests).
Change-Id: I462b88a814931dc2d4f1e72d07e3daf64768a399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144994
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
We now track decorated type parameter bounds similarly to how we track
ordinary type parameter bounds in the FixBuilder, by having a single
static instance of a DecoratedTypeParameterBounds class that keeps
track of the mapping.
Change-Id: I49196e8a506ca8765857b3d47a355b7aaaa1918e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134411
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
To avoid inserting unnecessarily complex casts, we want to normalize a
type like `void Function<T extends Object?>()` to the equivalent `void
Function<T>()`.
Change-Id: Ied10e7735511b732eaeca027e621b4ef6997df59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133820
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The visitSimpleIdentifier method was failing to return a DecoratedType
for the case where the identifier was `void`.
In practice this didn't matter, since the only time the type returned
from visitSimpleIdentifier is used is when the the identifier is used
as an expression, and `void` can't be used an expression (i.e. `var
voidType = void;` is illegal).
Nonetheless, it's nice to silence the warning, and it seems like it
increases safety to return a value from visitSimpleIdentifier in all
cases.
Change-Id: I239b98b9e5932195e6884738728d26d86c6ab519
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133336
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Replace it with TypeSystem from lib/dart/element/type_system.dart,
or (internally) with TypeSystemImpl.
We keep the old TypeSystem where its is exposed from API:
- ResolveResult.typeSystem
- AnalysisSession.typeSystem
- AnalysisContext.typeSystem
We will make changes to these as a breaking change later.
Change-Id: I40ca53ea77e440457c6d0f3832ec3b6286bacdf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125770
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously we were using `neverClosure`, which made the tests very
lenient; they accepted any node with an edge pointing to `never`
through a sequence of zero or more hard edges to be non-nullable.
While it is true that any such edges will be migrated to be
non-nullable, in our test cases we nearly always know that we want the
node to point to `never` through exactly one edge. So it's worth
making the tests verify this.
Change-Id: I2783fd41628961e0cd31b95edd396defd0b26593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125550
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
When promoting a type parameter, we need to create an intersection
type (e.g. "T & int"). Such a type is represented in the analyzer and
the front end as a type parameter type pointing to the same type
variable, but with a different bound.
Change-Id: I1655f9242d913ca958c279cc80c3f6329f6b396d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122581
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL combines the EdgeOrigin and EdgeOriginWithLocation classes, so
that all EdgeOrigin objects are associated with source locations. And
it separates the EdgeOrigin and PotentialModification roles of the
ExpressionChecks class into two separate classes.
This will enable a follow-up CL that switches the EdgeOrigin class
over to track source locations via AST nodes rather than offsets,
which will in turn allow rich information to be delivered to the
client about how the nullability graph relates to source code.
Change-Id: I736f60f93681fbbfbd5f9ee9a5589f99f819b9aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117282
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This should address ~13 exceptions whose stack trace includes the line:
_AssignmentChecker._checkAssignment_recursion (package:nnbd_migration/src/edge_builder.dart:2089:7)
Change-Id: I74e78885c996b637d73f80ca2dabba0226fa1fff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116366
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This should address ~25 exceptions whose stack trace includes the line:
EdgeBuilder.visitMethodDeclaration (package:nnbd_migration/src/edge_builder.dart:843:7)
Change-Id: I0076592f43f18c68f499fc9a80347a73033f8919
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115802
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Should take care of ~152 exceptions having this line in their stacktrace:
AlreadyMigratedCodeDecorator.decorate (package:nnbd_migration/src/already_migrated_code_decorator.dart:40:9)
Change-Id: I5a97470431b36b2c0ef88c15281b1eb51156b05f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114758
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Introduce a notion of a "node matcher" which abstacts knowledge of how
to match certain kinds of nullability nodes. This significantly
simplifies the tests of substitution nodes; instead of digging through
the graph to find the substitution node, asserting that it is a
substitution node, and then asserting that it has the right form, we
can simply use the existing `assertEdge` method to assert that an edge
exists with the appropriate kind of substitution node as either its
source or destination.
Change-Id: I1a483f18669fd0cf8075deb60e61a1930a40c4f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114630
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I have a lot more testing of decorated types to land in follow-up CLs;
this CL introduces a mixin containing helper methods that should make
that testing a lot easier.
Change-Id: I29c17ffb4af65498fcd85704dc404343429e09ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112847
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov