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 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>
In the future this could change to simply be a `Set<HintActionKind>`, so
that the `AtomicEdit`s can be calculated lazily. However, for the first
pass, they are calculated eagerly. This model lets us do that.
Change-Id: I07108ae0876d5e0efe7b35559cedb4cbd1c13605
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147624
Reviewed-by: Paul Berry <paulberry@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>
Previously, we only included edges in the trace view, which resulted
in a lot of missing information. Generally the reasoning process
looks like "type at A is nullable because of an expression at B, which
propagates nullability from a type at C, which is nullable because of
an expression at D, etc." This change makes the trace reflect that
reasoning process better.
Change-Id: I27d1b7aac736529b6f1fa2f7be8dea0d3eca9a6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139064
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This establishes the base functionality. A lot of follow-up work is
needed from here:
- Each trace should have an entry at the top of it pointing to the
thing that was made nullable.
- The source code links in traces don't include lengths, so we can't
highlight whole identifiers when the user clicks on a link.
- Description strings are currently generated by running toString() on
the individual nullability nodes and edges, resulting in long-winded
and useless descriptions.
Change-Id: Ibb370bae6bedc7a8c86092462785023002a48ac3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/138481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It didn't wind up being used, and its presence limits our ability to
modify the graph propagation algorithm (which I plan to do in a
follow-up CL).
Change-Id: I48a9b879f25295075e8d95eb3fb0185839303957
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133425
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
The new FixBuilder component of the migration engine communicates the
changes it produces using a "changes" data structure of type Map<int,
List<AtomicEdit>>, and is not compatible with the old
SingleNullabilityFix class (which made the incorrect assumption that
each SourceEdit was associated with a single fix). This CL changes
the migration engine's instrumentation API to use this data structure,
and changes its listener API to avoid reference to the
SingleNullabilityFix class. This allows SingleNullabilityFix to be
deleted.
This required changing AtomicEditWithReason so that it can hold
multiple fix reasons, and a NullabilityFixDescription. It does so
using a new object, AtomicEditInfo, and AtomicEditWithReason is
renamed to AtomicEditWithInfo.
In addition, the old FixInfo class is removed, since it carries the
same information as the new AtomicEditWithInfo class.
This required deleting the "incremental workflow" functionality from
UnitRenderer. This functionality was disabled, and I believe it
wouldn't have worked anyway (since it, too, made the incorrect
assumption that each SourceEdit was associated with a single fix).
Change-Id: Id965cfd803b408c66f15436017b87fc3e46521c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132306
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
With this change, we no longer use the "never" graph node for:
- instance creations
- explicit references to `this` or `super`
- the static type of `throw` and `rethrow` expressions
Change-Id: I995be86ee0f4d8002c70cf98e7e5d2767529d00b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125226
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>