Prior to this fix, if the user's package had a relative import from
outside `lib` to inside `lib` (e.g. from `test` to `lib`), the
migration tool would regard the imported file as being reached via a
`file:` URI. This caused it to get confused and complain that the
user had a dependency on unmigrated code (this happened because the
check for dependency on unmigrated code excluded the user's files via
their canonical URIs, and files inside `lib` use `package:` for their
canonical URIs).
To fix the problem, we modify the check for dependency on unmigrated
code so that it excludes the user's files via their path rather than
their URI.
Note that relative imports into the `lib` directory are discouraged by the style guide*, but it still seems worth fixing this bug since they do crop up in the wild.
*https://dart.dev/guides/language/effective-dart/usage#dont-allow-an-import-path-to-reach-into-or-out-of-libFixes#45780.
Bug: https://github.com/dart-lang/sdk/issues/45780
Change-Id: Iff41ca0059d78bbb812dd6f421be6458e7049895
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196344
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that `MigrationCliRunner.shouldBeMigrated` has the correct
signature and internal clients no longer use
`MigrationCliRunner.shouldBeMigrated2`, we can remove
`MigrationCliRunner.shouldBeMigrated2`.
Change-Id: I33bdc78a603c859dd8bf1928f2dbc23233ae5e7c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178763
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `url` argument is changing from `Object`, accepting either `String`
or `Uri` at runtime, to `Uri` for better static help.
https://github.com/dart-lang/http/pull/507
- Switch to using `Uri` for requests. Where sensible push this type into
the signature of the surrounding method.
- Make some updated method private where they were unnecessarily public
which makes it harder to have confidence when looking for usages.
Rename a method with an unnecessary `get` name.
Change-Id: Ibf075741d6b9d292349b15f1dc84004981729aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179368
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This change changes `MigrationCliRunner.shouldBeMigrated` to forward
to a transitional method `MigrationCliRunner.shouldBeMigrated2`, which
lacks the now-unused `context` argument. After this lands, internal
clients will be switched to overriding/calling `shouldBeMigrated2`
instead of `shouldBeMigrated`.
Once no clients remain that refer to `shouldBeMigrated`, the `context`
argument will be removed from it (this will be non-breaking since
`shouldBeMigrated` will at that point be unreferenced outside the
nnbd_migration package). After that, we will switch clients back to
overriding/calling `shouldBeMigrated` and eliminate
`shouldBeMigrated2`.
Change-Id: If9b476878260a5777f3346486d44c805dc361691
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178761
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Rename isPreviewServerRunnning to isPreviewServerRunning
* Fix top "Migrating" checkbox upon navigation.
This change does not completely solve google3-compatibility, just the
web preview UI portion.
Work to improve any opt-out `// @dart=2.9` comments will follow.
Change-Id: Iee38650ab732179d82060b14bc7b657e3c560543
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178160
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Since the EdgeBuilder overrides VisitNode, it wasn't getting the
benefit of the error recovery behavior provided by the
PermissiveModeVisitor mixin. This CL replicates some of the
functionality of PermissiveModeVisitor in the EdgeBuilder._dispatch
method so that it applies throughout the EdgeBuilder's visiting
process.
This uncovered a second bug: when an exception is reported, and the
user hasn't passed in the `--ignore-exceptions` flag, the migration
tool tries to exit immediately by throwing an error of type
MigrationExit, but this was being caught by the error recovery logic,
so the tool wouldn't actually stop reliably. This CL changes the
exception reporting code so that it re-throws MigrationExit when
necessary to ensure quick termination.
Change-Id: Ifd2faf8edb7cd0087c45e20a747ab7f1790ef1c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174420
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Checking and unchecking a directory toggles the status of all child files which
are 'migrating' or 'opting out.' Files which are already migrated do not
change.
Checking and unchecking a file updates the status of all parent directories.
Directories with both 'migrating' and 'opting out' files are 'indeterminate'.
The difference between 'file' and 'directory' NavigationTreeNodes was
getting too hairy so I split into two subclasses.
Removed the keepingOptedOut status and added the indeterminate status.
Bug: https://github.com/dart-lang/sdk/issues/44101
Change-Id: Iea1a8c07b08c3d7956db51ca372437093457fe7f
https://github.com/dart-lang/sdk/issues/44124
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173600
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Previously, the user experience was an `UnimplementedError` with no
further information. Now the user gets an error message telling them
how they need to update the pubspec, which I believe was the original
implementation intent.
Note that the field `_packageIsNNBD` has been removed. Although the
comment for this field said it was tracking whether the package was
opted in to null safety, it actually had no effect (since the only
code path that would set it to `false` was after the
`UnimplementedError` and thus unreachable).
Change-Id: I3cef2f0a7203941b22e37e3ae1bee14806cfc9c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171621
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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>
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>
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>
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>
The file might be edited in one of a few ways, depending on what it contains.
Previously we read and edited pubspec, which is also YAML, so this
implementation borrows a lot of that, and renames several "pubspec" elements to
be "yaml" elements.
I try to cover in tests various odd existing analysis_options.yaml situations,
so that we try to never crash, or corrupt on weird input here.
Fixes https://github.com/dart-lang/sdk/issues/43806
Change-Id: Ifc57d583e98d798fd7bca748bbe4afef272edab5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167862
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Rather than produce an error immediately upon encountering an
alredy-migrated library, we simply skip processing it; this causes its
elements to be added to the nullability graph on demand, just like for
already-migrated dependencies.
We still check for the possibility that *every* file in the user's
package has already been migrated, and issue an error if so (rather
than just doing nothing); this should help avoid user confusion if the
user tries to re-migrate an already-migrated package.
Bug: https://github.com/dart-lang/sdk/issues/42308
Change-Id: I8dd81a9c6ff2bb23ede91e89d1152bd7726dec32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167202
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We now store both environmentVariables and injectArtificialException
in the _MigrationCliTestBase class, and refer to them wherever they
are needed, so we reduce the amount of plumbing we need to do.
In a follow up CL I'll be adding more behavior injection using the
same technique.
Change-Id: Ib736373f7a92a46922964d3c5c59d35bf72d618a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151300
Reviewed-by: Janice Collins <jcollins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry