The previous implementation of the tool (based on dartfix) used
diffing code that was pretty deeply tied into dartfix, and didn't
produce good quality output for migration, so I've replaced it with a
new implementation.
Change-Id: Id3679435bf59c73145eacb6eaee1b6ce16dd61f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146442
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
If an external customer reports an issue with the migration tool using
the links we provide, they won't have the necessary github privileges
to apply labels to the issue, so we want to make sure the default bug
title clarifies that this is a customer-reported issue with NNBD
migration.
Change-Id: I55bf8c16062b1b9e8c25415addc99dd1c378b724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146621
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We produce a diagnostic under the following conditions:
- For compound assignments, if the type read from the LHS is nullable
(this is illegal after NNBD, and requires user intervention to fix).
- For compound assignments, if the type returned from the combiner is
not assignable to the LHS (this was required prior to NNBD, but it
is a stricter condition after migration, both because the LHS might
have a non-nullable type, and because implicit downcasts are not
allowed).
- For null-aware assignments, if the type read from the LHS is
non-nullable (this indicates that once strong mode is enabled, the
assignment will be dead code).
Bug: https://github.com/dart-lang/sdk/issues/38676
Change-Id: Icb242ba36437e38364ada069880831eb05e3a513
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145664
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Fixes https://github.com/dart-lang/sdk/issues/38291
This change also involves moving the "package" where test sources are
written and analyzed; It used to be /home/test (or /project in some
places); and a pubspec.yaml was written (or a .packages file) which
specified the package's name was "test". However, this conflicts with
adding an entry for a mock copy of the actual _test_ package. A
.packages file cannot have two entries for a package named "test", so
the package where all test sources are written is changed to "tests"
(located at /home/tests).
Change-Id: I462b88a814931dc2d4f1e72d07e3daf64768a399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144994
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This will allow us to publish the migration tool on pub, so that we
can ship improvements to it that aren't coupled to SDK releases.
As of this CL, basic read-only functionality of the preview site is
working. However, the ability to apply migrations and add hints to
existing code has not yet been tested.
Change-Id: Ib1588e741efa7be7861fa75b962fd1565765e794
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144808
Reviewed-by: Janice Collins <jcollins@google.com>
Originally, edit links were implemented as generic "post links," that
had no special handling except to fire a post request.
At this point, this is no longer the case. We at least want to
specialize the error message, and we have TODOs to do more
specialization (targeted reloading of the UI).
Note that 'edit-link' is already a class, it refers to the edits the
migration tool suggests as the migration. Therefore I used the class
'add-hint-link' instead of 'edit-link.'
Lastly, post-links were styled like buttons. But they are not the only
links that should be styled as buttons now, so just use that class
instead of having special styling.
Change-Id: I8241a5ec24e6a290b94a75327c06257abdfc011b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144660
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
NonNullableFix now communicates with DartFixListener through the
abstract interface DartFixListenerInterface; this will allow us to
build a version of DartFixListenerInterface that doesn't require the
analysis server.
Change-Id: I106d769b0e6ed49a916e2f1665a7e31a9a63be86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144471
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
The migration logic doesn't need to access the AnalysisDriver object;
it just needs access to the AnalysisSession (which the driver holds).
By changing the interface so that it requests the session directly, we
pave the way for making a version of the migration tool that doesn't
require the analysis server.
Change-Id: Ib99725bbb2c1728a4c57b46659e9d94cbfe65ee0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144470
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
This removes most of the imports from nnbd_migration to
analysis_server by replacing them with abstract interfaces that are in
turn implemented by classes in analysis_server.
Change-Id: I9be9a5bd69b1664f0fea9ff3b6ba4678f134f0e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144468
Reviewed-by: Janice Collins <jcollins@google.com>
Previously, all parameters returned by
MigrationResolutionHooksImpl.getExecutableParameters were synthetic
ones that came from translating the executable element's decorated
function type to its final post-migration type. Synthetic parameters
can't be field formal parameters, so this meant that when the
FixBuilder was re-resolving a constructor containing field formal
parameters, references to the field in the constructor body would get
incorrectly interpreted as pointing to the parameter rather than the
field, and that would cause them to be subject to promotion.
The fix is to only return synthetic parameters from
MigrationResolutionHooksImpl.getExecutableParameters when the
executable in question is in a library *not* being migrated. When
it's in a library that *is* being migrated, we can just return all of
the executable's parameters without translating them, because we know
that the parameters themselves have been visited by the NodeBuilder
and EdgeBuilder, hence they all have thier own associated decorated
types.
Fixes#41405.
Change-Id: I5e3c411dc92fe242a959a5670b9253fbccea2b31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144122
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Consider the following code:
int f(int i) => i == null ? null : i + 1;
Previously, migration would mark the return type of `f` as nullable
even if `i` was non-nullable. This happened because the edge
connecting the explicit `null` (in the "then branch" of the
conditional) to the return type of `f` is created after visiting the
conditional expression, so the condition guards are no longer in
scope.
With this CL, we create an extra graph node when needed to ensure that
the guard is applied to the expression type.
Change-Id: Ie00eea0b431905241612c6661d69bdb55c0910d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144121
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
This change adds the ability to detect when one branch of a
conditional expression is weak-only due to nullability. For example,
in the following code:
int f(int/*!*/ i) => i == null ? g(null) : i;
int g(int j) => ...;
the call to `g` can only happen in weak checking mode. The migrator
also now understands that j only needs to be nullable if i is
nullable.
Fixes#41555.
Partially addresses #41551.
Bug: https://github.com/dart-lang/sdk/issues/41555
Change-Id: I02c9c3072f0104db0f1a5b432fb1f2f8f06d5282
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144120
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
In the FixBuilder, when we are discarding one of the branches of an
if-statement or if-element due to it being weak-only, we only visit
the branch we're keeping; this avoids trying to make changes to code
that's being removed. However, if we are keeping both branches and
simply warning about one of them being weak-only, then we need to
visit both branches so that fixes are applied to both of them.
Change-Id: I26a1bfcb5f2ef4a111b1117637bce74e42d3db07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously, the spaces inserted by EditPlanner.addCommentPostfix
didn't carry the correct isInformative flag, so they would show up in
final migrated output.
Change-Id: I100ba88040ebff9ae5d406c49b242f6fb17ce7b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143887
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously we considered such code "dead", but it's not really dead
until Dart 3.0. Removing it changes weak mode semantics, and we don't
want to do that automatically.
Fixes#41231
Change-Id: I6a88f016b4f3fcba160dcb738558867219715cbb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143941
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Technically, accepting a hint requires two edits, one to remove the
`/*` and one to remove the `*/`. But we only want it to show up as
one edit in the "Proposed Edits" pane.
Fixes#38471
Change-Id: Ica7880a2ffab98715a1c9f3bbe723363fd481086
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143484
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously, if we migrated a code snippet like this:
void f(int/*?*/ i) {
/*late*/ int j = i/*!*/;
}
the migration result would leave the hints and add the hinted text,
resulting in:
void f(int?/*?*/ i) {
/*late*/ late int j = i!/*!*/;
}
We now simply remove the `/*` and `*/` surrounding each hint (with
whitespace corrections as needed), to produce:
void f(int? i) {
late int j = i!;
}
Change-Id: Ic4e1216cb4693d73d71c9ab1a37d5cc15b8ef334
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143460
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Currently these are just equal to sourceNode.offset and sourceNode.end
respectively. In a follow-up CL, I'll introduce situations in they
might differ (in particular, the edit might include changes to a
nullability comment that precedes or follows the sourceNode).
Change-Id: I1c728454bafe9b154662dbb4c21d28fc62415abf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143340
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Paul Berry