This adds support for analysis domains that plugins contribute to by
sending notifications. I've only implemented folding so far, but most
of this CL is to cache results from plugins and to adapt sending server
capabilities.
Instead of using a NullNotificationManager, the LSP server now uses a
regular NotificationManager, except that results won't be forwarded to
clients. LSP handlers will fetch partial results from plugins and merge
them with data from the server that will be computed when needed.
I've extracted the server capabilities calculation from the init
handlers into ServerCapabilityComputer. It will also contain the
interestingFiles glob from active plugins and re-register capabilities
whenever plugins change.
Change-Id: I9869240cbfa284592e952498933e638b89a2a763
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/142981
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
These fields were not being used. Removing them will make it easier
to move these classes into pkg/nnbd_migration.
Change-Id: I7528bc07e5efd3936a9c6fd1635415e139d5df43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/144466
Reviewed-by: Samuel Rawlins <srawlins@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>
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>
In addition to implementing the feature, this CL updates one of the
contributors to use the new feature as a way of testing it. I haven't
looked to see whether it impacts the metrics, but I wouldn't expect much
change anyway because of the small number of completions that are likely
to be effected by this change.
It might be interesting to start thinking about ways to measure the
impact of individual features.
Change-Id: Idd0040a774e5fd9a6e3f6c29d0aa7fd762676fbe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143622
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jaime Wren <jwren@google.com>
`isIgnorable` is the new way to determine whether a report from the
analyzer can be ignored. Codes with an ERROR severity are not ignorable,
and the new SecurityLintCode is not ignorable.
Change-Id: Ied72f1b61808eda088b947b8836e0cf1dfdd9850
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143331
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Mutate datastructures to match disk contents. Leverages offset mapper,
by rebasing the migration mapping onto the disk changes which occur in
sequence.
Add an integration test for preview site tests that confirms multiple
changes workflow works, including regions and navigation, including
using the changed edit offsets.
One thing that is not updated is traces. It seems that trace entries are
misusing "offset" by storing column values. Without that, adjusting
trace entries is not trivial. I have not looked into how difficult it
would be to correct this. Traces still *work*, they just may point to an
incorrect column. This is not easy to notice, but worth fixing in the
next CLs.
Another potential consistency improvement would be to use the offset
mapper to handle regions so that they do not need to be updated this
way. This would be more consistent with how other things like navigation
did not require updates once the offset mapper was done correctly.
Another quirk is that this API for performing edits does not *necessarily*
lend itself to reruns. For this CL, I decided to check when the edit is
"insertion only" and therefore easy to do incrementally. However, the API
allows for things like mass deletions that might be trickier to handle in
general. In this case, it will still do a rerun.
Change-Id: Ib88bb32592f54502d69b58ccab71ffb0b5f8040e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143325
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Without this, rerunning causes the change list to grow, including all
prior changes. When users hit the apply migration button, the result is
corrupt.
Change-Id: I3b57b24be25e897ac6c976254d04a78dbb3a5a7e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143324
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Currently not hooked up to any special styling, but will hide the "apply
migration" button.
Also currently not set to true by any workeflows, but that will of
course change in follow-up CLs.
Change-Id: Ie0ef64361dac40b19bf08497c1c4f92a80b0891d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143323
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Jaime Wren