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>
When a method call includes a named argument such as:
f(named: x)
the analyzer represents the AST node `named: x` as an Expression. But
it's not safe for the migration tool to try to modify it in the same
way that it modifies other expressions (e.g. by surrounding it with
`(...) as Type`), because that would produce a parse error.
Improves the analyzer behavior for #45583. Note however that this is
not a complete fix yet; see the test case included in this CL for why.
Bug: https://github.com/dart-lang/sdk/issues/45583
Change-Id: I79ffcdd22654221ff7e0784b3355ecfd2ec0f01c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194008
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, if the migration tool encountered a Future expression with
a bad type (e.g. a Future<String?> where a Future<String> was needed),
it would "fix" the problem by introducing a cast. That is nearly
always the wrong thing to do; what we want to do is null check the
value that the future *completes* with.
This CL changes the migration tool so that it fixes this case by
appending `.then((value) => value!)` to the future expression.
Fixes#45472.
Bug: https://github.com/dart-lang/sdk/issues/45472
Change-Id: I7a35b54f673936e2e4b0f8f3a077ba8bf684b4eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Since `this` is essentially a variable in extensions, it should be
treated similarly to variables in terms of inference of non-null
intent; for example, if an extension declaration contains a a method
that unconditionall dereferences `this` (either implicitly or
explicitly), that's a good indication that the user probably doesn't
intend for the extension to be applied to nullable types.
Fixes#44675.
Bug: https://github.com/dart-lang/sdk/issues/44675
Change-Id: I004328f5b1fd6710954363c07f4e9db6bc6ac2cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180268
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This partially addresses #44675 by ensuring that if an extension's
extended type is nullable, we won't try to insert an unnecessary null
check at the call site.
It's not a complete fix, though, because we still don't account for
obvious indications of non-null intent when analyzing the extension
definition itself. I plan to address that in future CLs.
Bug: https://github.com/dart-lang/sdk/issues/44675
Change-Id: Ia0ca37b89470a2d4882ae32cd842552ffd34930e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180263
Reviewed-by: Samuel Rawlins <srawlins@google.com>
After a variable is write captured, references to it should no longer
be considered to express non-null intent, because we can no longer
guarantee that an initially null value of the variable would
definitely lead to an exception.
Change-Id: I44c65350291a4c44cdb4b19529b13149d8170e34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180100
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, code inside of local functions was treated as though it
appeared inline for the purpose of determining non-null intent. As a
result, a return statement in such a local function would cause any
code references that followed to be incorrectly treated as *not*
expression non-null intent.
Fixes#44703.
Bug: https://github.com/dart-lang/sdk/issues/44703
Change-Id: Ia74da007eb5424c784d41afeb0e2da4771578553
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180081
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the nullability graph propagation algorithm identified
non-null intent prior to inference of `late`. As a result, late
inference would be skipped for any variable with clear non-null
intent, so late inference was a lot less effective than it should be.
This requires updating several test cases where `late` should have
been inferred.
Change-Id: I0412ee7045e654185af08cc12b6ca1e6866112af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/180080
Reviewed-by: Samuel Rawlins <srawlins@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>
Paul Berry