In upcoming CLs, I'm going to need access to the EditPlanner when
finalizing edit plans, and I'd rather do so by making finalize a
method on EditPlanner. Doing so now to make future code reviews
simpler.
Change-Id: I6182e2224b548b2919f0c8f454f558b72c17e5d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130926
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This factory class serves three purposes:
- In a future CL, it will contain fields to customize the global
behavior of the edit plans that are created (e.g. whether code
should be removed or commented out).
- In a future CL, it will contain a pointer to the original (text)
contents of the source file. This will allow edit plans to make
more sophisticated changes such as adjusting indentation.
- In a future CL, it will contain methods for creating common kinds of
"extract" edit plans such as null-checking an expression or making a
type nullable. (Currently the client must create these edit plans
using EditPlanner.extract, which has an error-prone API).
Change-Id: I87ac75b73003d0e7b416e3d2121eadb2770da5ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129802
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We were getting a static error in package:logging for
```dart
Zone recordingZone;
// ...
runZoned(() {
recordingZone = Zone.current;
// ...
});
// ...
expect(records.first.zone, equals(recordingZone));
```
That is a static error if we don't make `recordingZone` late or
nullable.
Change-Id: Iab5e47dd8df375c7dc5283ce4570ad1321ba919e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130738
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Turns out the flow analysis bug was actually an issue with calling
toString() on an enum. This happened to throw the same type of exception
as caused by the shared part file, so it blended in. Flow analysis was
not itself broken.
Tested the other methods on enum too, but no others seemed to have this
problem.
Change-Id: I5e9e1be3f02adf0177c276c63d0c4f4fa2cb94db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130622
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
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>
The shell script now makes use of github fetching and `pub get` to deal with dev_dependencies
and other things missing from the SDK. Also added the remaining packages not in the SDK, but
in group 1.
Change-Id: I6ae9b169eb8a419d73c66f08fb3973b49a96efb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128287
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Paul Berry