When I first implemented this I thought that checking exports wasn't
needed, since it's not allowed for a migrated library to re-export
symbols defined in an unmigtated library. But it turns out we still
do need to include exports in the check, since there might be migrated
libraries that are only reachable in the transitive dependency graph
via an export, and we need to check that *those* libraries don't
import unmigrated code.
Bug: https://github.com/dart-lang/sdk/issues/44061
Change-Id: I280b4117373a3320fc1efe65abe24e344199754c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170840
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Instead of running `pub outdated` to see if the user's dependencies
have been migrated yet, the migration tool now examines all of the
transitive import dependencies of the user's code to see if they are
opted in to null safety. This produces a more accurate result than
`pub outdated`, because it is able to ignore files in transitive
package dependencies that aren't reachable via imports
(e.g. references to `package:analyzer` brought in by `package:test`).
Fixes#44061.
Bug: https://github.com/dart-lang/sdk/issues/44061
Change-Id: I38465bcbf35e8552f0060b5d51c0f1cfc5d18c7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170561
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This shows progress for work which happens after the migration suggestions have
been generated. This work is generating instrumentation details for the front
end.
When migrating the analyzer package, the progress indicated by this third
progress bar takes approximately the same time as generating suggestions (on
the same order of magnitude).
Fixes https://github.com/dart-lang/sdk/issues/44074
Change-Id: I0b40dd5e587b718bd1ef56d64f03929924cc430a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170563
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Early in the development of the migration tool, due to language
versioning support being incomplete, it didn't have a good way to
distinguish opted in from opted out code, so we had the convention
that any code not being migrated was opted in. Now that we have
language versioning support, we need to explicitly opt that code in.
Without this change, we'll get bogus failures when we add logic to
detect unmigrated dependencies.
Bug: https://github.com/dart-lang/sdk/issues/44061
Change-Id: I12920ea75b8af2142a044314b89b76bb602897c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170560
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
As discussed in
https://github.com/dart-lang/sdk/issues/44031#issuecomment-720967259,
we want to encourage users to publish null safe packages with an SDK
min constraint matching the SDK version that was used for the
migration, e.g. `2.12.0-18.0.beta`. However, we also want to make
sure that users doing migration via internal, dev, or bleeding edge
builds publish their null safe packages don't wind up inadvertently
publishing packages that are un-resolvable with the latest beta SDK,
so if the user is on one of those versions, we'll set their SDK min
constraint to `2.12.0-0`.
And of course, once the feature ships to stable, we'll want users to
publish their null safe packages with an SDK min constraint matching
the version in which null safety shipped to stable.
This CL implements all of that functionality, and tests it by
overriding the `version` file in the analyzer's mock SDK.
Change-Id: Ib9ed97e691271da0ed391a6c1a5fe209aa959dce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170380
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, when analyzing a call to an iterable method that could
potentially be transformed into an `OrNull` extension, such as:
allMatches(str).firstWhere(..., orElse: () => null);
the migration tool would erroneously identify some subexpressions of
the call target (`str` in this example) as the argument supplied to
`orElse`, resulting in a crash.
This CL fixes the logic so that we use an `identical` check to verify
when we are looking at the argument to `orElse`.
Fixes#43956.
Bug: https://github.com/dart-lang/sdk/issues/43956
Change-Id: I2f4a0e81becf789cab5334d4926e014bda2772f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170162
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we hard a hard-coded set that included all packages added
by unit tests, which created confusion when writing new unit tests.
Now, `addPackageFile` records a list of all packages and
`package_config.json` is automatically generated just before analysis
begins.
Change-Id: I3393c0266a54d051ffa7601e74753a75857635e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170024
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently the migrator can add `@required` from the preview, which will crash
the preview upon rerunning, if package:meta is not imported.
This change instead adds a /*required*/ hint when meta is not imported.
Additionally, /*required*/ is understood by the migrator just as if it were
`@required`.
Fixes https://github.com/dart-lang/sdk/issues/43751
Change-Id: I1ea532246b956feacedd179146372b13c65003df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
In the beta release, we plan to recommend that people set their
pubspec SDK constraints to `>=2.12.0-0 <2.12.0`, so this change
updates the migration tool to have that behavior.
In the second beta release we'll change switch the upper bound to
`<3.0.0`.
Change-Id: Ib90e893bebaebea968b19e7de663cbbbca570f84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169143
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This was causing visual clutter by making informative regions offset
from regular code. Worse yet, there was a "double vision" effect
because the top of the underlying non-offsetted text could sometimes
be seen behind the informative region overlay.
Change-Id: I206c74b3d91f305a21494b767ec27f396a8513b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously, we were switching test paths to drive `D` at the start of
the test, after the `package_config.json` file had already been
generated to drive `C`; as a result, it didn't apply. We will need
the `package_config.json` to apply when we flip the null safety flag
(so that the inputs to the migration tool are considered opted out
prior to migration). This CL reworks the test so that the paths are
modified as part of test set-up, so `package_config.json` gets put in
the right place.
Fixes#43883.
Bug: https://github.com/dart-lang/sdk/issues/43883
Change-Id: I08f79ddb07d7a5ecf640370a32334a7ceb92ceff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169421
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With this change, the functionality of changing iterable method calls
such as `.firstWhere` into extension method calls such as
`.firstWhereOrNull` is working well enough that I think we can switch
it on.
We don't update the pubspec properly yet; that will be addressed in
follow-up CLs.
Change-Id: I758332e9752b12d399ecb5c70cf37bbc8da77d6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168988
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
We don't want inserted lines to receive their own line number for two reasons:
- It makes the line numbers displayed by the migration preview fail to
line up with the line numbers in the user's editor (since the lines
haven't been added yet)
- It makes navigation links within the migration tool point to the
wrong place, since these links are computed based on analysis of the
pre-migration code.
So instead, we supply a line number string of `(new)` for inserted lines.
This required refactoring the algorithm for
`UnitRenderer._computeRegionContent` a bit. Now, instead of trying to
accumulate the output HTML string all at once, we produce it one row
at a time, first accumulating the line text in a StringBuffer, and
then once the end of the line is reached, attaching the line number to
form a table row. Then we join together all the rows into a table
when we're done.
Change-Id: Ie18632186ddd0f4f5f33d4da41b4943759699e1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168987
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously UnitInfo.regions contained just information about edits
that we wanted to alert the user about; it didn't contain information
about unimportant edits like adjusting whitespace.
This caused problems when trying to make complex edits (like those
necessary to transform a `.firstWhere` call into a `.firstWhereOrNull`
call) because it interfered with UnitRenderer._computeRegionContent's
ability to properly compute file offsets.
So we now include all edits in UnitInfo.regions, and we distinguish
the unimportant ones by seeing that their `kind` and `explanation`
fields are `null`.
To ensure that important edits never wind up with `null` values for
these fields, we add assertions to the `NullabilityFixDescription`
constructor.
Change-Id: I89928150eb507524222d03acfae0b4770363443c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168985
Reviewed-by: Samuel Rawlins <srawlins@google.com>
The method we use to rename method calls to Iterable
(e.g. `firstWhere` -> `firstWhereOrNull`) causes a pair of consecutive
AtomicEdit objects to be generated: one to remove the old name
followed by one to add the new name. This was causing
InfoBuilder._explainUnit to update its output offsets incorrectly,
because it waited until after processing all of the AtomicEdit objects
pointing to a single source offset before updating the output offset.
What it needs to do instead is update the output offset (in the
variable called `offset`) after processing every single AtomicEdit.
Change-Id: I8ad51e20d4021c62c45542cec7f0f54a9ff3cf26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Well not quite all; migration_cli_test tests are a bit of a different
beast so I am going to tackle them separately. But this fixes over
1000 test failures, and should clean up test output for further
debugging of the flip CL.
Each test file needs to be in a package with a package config file
which spells out that it is _opted out_ of null safety.
Bug: https://github.com/dart-lang/sdk/issues/43883
Change-Id: I583f66119df57031fd80824111923e15e0f91782
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168900
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
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>
The output the migration tool generates when the web preview is
disabled shows a complete diff of all changes the tool will make, so
it's really a misnomer to call it a "summary".
Change-Id: I8c7d9f9870bf8beffb62f1d10d36a65b66c32657
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168381
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I'm looking into enabling NullSafetyUnderstandingFlag in the next
analyzer breaking change.
test_function_void_to_function_object() fails, and it seems that
the test class should use legacy TypeProvider, because `Object` is not
assignable to `void`, but `Object*` is.
Change-Id: Ib867e0eec7a387ed3ed1379a7ef34a58b16e54ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168125
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Paul Berry