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>
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>
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>
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 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>
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>
I see no reason why this would be useful.
But it might be harmful.
When we create file1 that imports file2, and call getFileSync(file1),
the analyzer will read both file1 and file2 while building the
file graph. So, when we then create file2, it will not be read unless
we call changeFile(file2). And we don't.
Actually, if we want to simulate how migration works, we should first
create all files, and then migrate them.
R=paulberry@google.com
Change-Id: I22ff994d346c4ad985e5d06a34e9fd854d451757
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
`FutureOr<T?>` is already nullable, because `FutureOr<T?>` ==
`FutureOr<T | Null>` == `Future<T | Null> | T | Null`. So the second
`?` is redundant.
Also fix a bug where we were treating a `Null` type as `Never` if we
couldn't find a reason to require it to be nullable; this was
inconsistent with how the FixBuilder was handling `Null` (which is to
leave it unchanged).
Change-Id: I5e0e4b7fb449988d8ff0dd87a2b4c3da4a6ecebb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155506
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
There were two problems:
- EdgeBuilder wasn't handling the extension override syntax at all,
causing a crash.
- FixBuilder wasn't overriding the behavior of
ExtensionElement.extendedType, causing a star type to be used as a
context for the target expression; this prevented the fix builder
from realizing when it needed to insert `!` after the target
expression.
Fixes#42455.
Bug: https://github.com/dart-lang/sdk/issues/42455
Change-Id: I5a9f66f83db73a796e72708022faefd527667e32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/42375
EdgeBuilder wishes to do its own GLB type-joining, as does FlowAnalysis.
When FlowAnalysis pushes a promotion in ifNullExpression_rightBegin,
and then in write, and then pops those two promotions to join them in
ifNullExpression_end, EdgeBuilder is not given a chance to make its
own GLB node. Instead promotion never happens: the DecoratedType which
is the variable's type is promoted to non-nullable, for the left side.
The DecoratedType for the right side expression is not considered
non-nullable, so the FlowAnalysis.join will always fail to promote.
TypeOperations.adjustPromotedTypes solves this. It is a no-op in all
implementations except in EdgeBuilder.
Additionally FlowAnalysis.write's promotion fails for the same reason:
the only type of interest is the declared type made non-nullable, and
no matter what, the writtenType is not a subtype of this.
TypeOperations.forcePromotion solves this. It is a no-op in all
implementations except EdgeBuilder.
Change-Id: Iba6b9a69583af8fe1aa23124c7d66047acfff495
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152104
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov