It also looks like the old clause detecting method invocations on
variables is no longer relevant. Removing it does not fail any tests,
p1g1 packages, or sdk/third_party/pkg/ packages.
Change-Id: Idcab49f00c6b5b38ba5f2ecf3f2a45787c13376a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129817
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
There were cases where types that are promoted with current type
promotion were not being promoted with improved type promotion due to
null-checks:
```dart
void f(x) {
if (x == null) {
return;
}
if (x is ...) ...
}
```
This was causing a bad state when trying to substitute type parameters
on methods if promotion usually succeeded.
Fix the crash by allowing migration to promote a non-null type to a new
type, and make that new type an intersection of the new type and
non-null.
```dart
if (x == null) {
} else if (x is List<int/*1*/>/*2*/) { // promote to List<int/*1*/>!
```
Change-Id: Icf9f74eb2b3eef887a29d4bfab7556ac126f49e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129540
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Consider:
```dart
List<num> x;
if (x is! List<int>) return;
x.toSet();
```
In this case, `x.toSet()` gets a `targetType` of `List<int>` due to new
promotion. However, the element of `toSet` is `Set<num> Function()`.
We provide the correct `targetType` in `getOrComputeElementType`, with
the correct substitution T/int. However, the resulting element has the
incorrect member substitutions T/num.
It is therefore no longer worth providing the `undecoratedResult`
argument, because it is not the correct answer. The only way to get the
correct answer is to undo the member substitutions, and reapply the new
substitutions. This is what `.substitute` already does. This plus other
CLs to always provide the implicit `this` type, together mean that this
code does everything it needs to.
In case this was done for performance, I timed it A:B, and both took
1:13s to perform trial_migration.sh
Change-Id: Iecf7e6893d56ec96af735814e5c9acb13854f67d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129329
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
This will allow FixBuilder and FixAggregator to be integrated together.
I have a branch in which they are integrated, but it is currently
failing some tests due to missing functionality in FixBuilder, so I'll
work on implementing the missing functionality before completing the
migration.
Change-Id: If3fd64665eef8a8373e5679978e3724eee6689da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129306
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
FixAggregator will form the last stage of the migration engine, taking
the output of FixBuilder (which is a map from AST nodes to individual
changes) and feeding it into the EditPlan infrastructure to produce
the complete set of edits for any given file.
In a follow-up CL, I will modify FixBuilder to make use of the
NodeChange classes defined here.
Change-Id: I73fd67d7e989194049d91f978a7d9134814d3265
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129304
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Initially this will be used in the NNBD migration engine to produce
migration output. Assuming it proves useful, in a future CL I'd like
to consider moving it to the analyzer_plugin package and using it as a
basic for all of the analysis server's refactorings.
Change-Id: I41ffc578ace3945fcfebb8eb824b6b5706dfba6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129302
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
There are no examples of a downcast involving a nullable type in the
current set of working packages. This tells me that it's rare, and that
this behavior should be good enough.
If we're wrong, this unblocks packages and we can revisit this decision
later.
Change-Id: Ic4e23cc6a848b83b2d1fb6c97ff513c3cc9fdb2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128778
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
This CL establishes the scaffolding for the new FixBuilder
architecture, and gets most of the previous tests to pass.
Several TODOs remain, which I plan to address in future CLs, however I
want to get the FixBuilder running end-to-end before doing so, so I
will work on that next.
Change-Id: Ic68b04c70b6cb8c72d04f00f9a027c3498f3acbc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128562
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In an upcoming CL, I will be replacing the FixBuilder with an
implementation that re-uses resolution logic from the analyzer. Due
to complexities with the analyzer's scope management, it won't be as
easy to test individual visit methods in isolation anymore, so this CL
modifies the FixBuilder tests so that they each visit an entire
compilation unit rather than just one or two AST nodes; this will
allow landing the rewritten FixBuilder without making further
significant test changes.
Note that in order to land this CL I had to had some temporary hacks
to the FixBuilder so that it could visit top level constructs
correctly. These hacks will go away when the rewritten FixBuilder is
landed.
Change-Id: Iffaaaa382070aa87c368e6fcc28034030a34b4ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This prevents the following crash:
Bad state: Missing declarated type annotation in /home/test/lib/test.dart; for Object
package:nnbd_migration/src/variables.dart 68:7 Variables.decoratedTypeAnnotation
package:nnbd_migration/src/edge_builder.dart 1378:26 EdgeBuilder.visitTypeName
package:analyzer/src/dart/ast/ast.dart 10012:49 TypeNameImpl.accept
package:nnbd_migration/src/edge_builder.dart 844:10 EdgeBuilder.visitIsExpression
package:analyzer/src/dart/ast/ast.dart 6372:49 IsExpressionImpl.accept
Change-Id: I23ed49ccbd3625d9f9fbc7e07a69be3c580896ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127457
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@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>
Mike Fairhurst