This splits Notification manager into an abstract base (which handles merging plugins notifications) and two concrete subclasses that can broadcast the notifications in the correct format for LSP vs DAS protocols.
Change-Id: I5fa2b643adc7bb46db0f06ddd2c997d8a736cbaa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149162
Commit-Queue: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This doesn't improve the scores in the small app I've been using, but
it does move forward all of the old relevance computation support that
I could find into the new relevance computations.
The other thing done in the old relevance support is some filtering.
For example, in an extends clause, mixins will be filtered out. This
would improve the relevance scores (by reducing the number of
suggestions) but it doesn't seem like it ought to be done as part of
the relevance computation. We should think about a good way to better
filter the suggestions.
Change-Id: Icc671ff033cc5a2d2356c61555844b944d8890b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149204
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
We used to be somewhat inconsistent about the choice of element kind for
top-level variables, getters and setters and fields, getters and setters
in classes, mixins and extensions. We no longer use GETTER and SETTER as
kinds, using FIELD and TOP_LEVEL_VARIABLE everywhere. This makes some
cases better and some worse, but improves the overall score across all
the completions in our metrics.
Change-Id: Idd0b10b3afe6023ecf39930b6a09abf28b3232bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148883
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The enhancement is that we can now create a const constructor if the
class to be created is being used as an annotation. We could also do
this if the class were being created from a constructor invocation, but
I didn't do that. This also doesn't handle creating a named constructor,
but I don't think it's any worse than before. If you disagree let me
know.
Change-Id: Idcff7bd0ac8def416b141b49b801f6798548405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148885
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This removes the need to keep the list of lints associated with a given
correction in two places, removing the possibility of those two places
being out of sync. It also fixes one inconsistency that was pre-existing.
Change-Id: Ic5ccbdeaa3eb07b013375cd0e1676fd6f89f57ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This feature boosts the relevance of suggestions for constant elements
when completion is requested in a constant context.
It didn't have as big an impact as I was hoping for in the small sample
app I'm currently using, but it did have a positive impact, so I think
it's worth adding.
Change-Id: I11eb18be798fc15caf8a33f222a20707aeaee2b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148782
Reviewed-by: Jaime Wren <jwren@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I suspect that I broke this recently with my refactoring work.
Unfortunately there were no tests to tell me that I'd done so.
An alternative would be to move the visibility checks into the
SuggestionBuilder. I'd been kind of trying to keep that class focused on
_how_ to build suggestions rather than _whether_ to build suggestions,
but there might be value in having the logic for _whether_ to build them
also be centralized. If so, it could either be in SuggestionBuilder or in
a separate (wrapper) class. Thoughts welcomed.
Change-Id: I71198583496a685dd7865ef7955ef2dabaa3e1f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148680
Reviewed-by: Jaime Wren <jwren@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
These interfaces acted as a temporary bridge to allow analysis server
core classes to provide services needed by nnbd_migration without
forcing analysis_server to depend on nnbd_migration; that in turn
allowed the analysis server to provide migration services to dartfix.
Now that we no longer use the analysis server nor dartfix for
migration, these interface classes are no longer needed.
As of this commit, the nnbd_migration package no longer depends on
analysis_server.
Change-Id: Ia923d91dd59c9a612000da8b0c9ead8a68686d89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148560
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
The ChangeArgumentName "fix" is one of a small number that can produce
multiple fixes. I'm proposing that we support these by adding objects
that can dynamically produce zero or more CorrectionProducers depending
on the situation being flagged as an error.
Change-Id: I37c06ffefd46f4b8478d127d1b537b3bc840e024
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The code to check the element kind was not being used in a few places
because (a) the generator wasn't always generating a table when it
should and (b) the key for the table wasn't always being set when
creating the OpType. Both of these issues have been mostly addressed.
That required re-generating the element kind tables.
There were several places where context type information wasn't being
used when building suggestions. This has been fixed for all the places
I'm currently aware of.
There were a couple of places where the context type wasn't being
computed where it could have been. I have fixed the places I'm aware of.
Context types were not being computed anywhere because of a bug that
has now been fixed.
There is now one place that computes and caches the context type, which
should improve performance slightly.
I also removed some dead code that I discovered in the process of making
the other changes and cleaned up a couple of places in the code that
were suboptimal.
Change-Id: Ieae8dcc71b986841be3078d6e0b3a653c35384b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148237
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Sorry about the size of the CL. I can split it up if you'd like.
In order to do this I added a listener to SuggestionBuilder so that we
could capture the data as suggestions are being built. If it turns out
to be a performance problem we can remove it before shipping it, but it
should only impact the new relevance path, which isn't being used yet in
production.
This splits the "worst" and "slowest" (formerly "longest") results into
three groups. I might find it useful to split them out into more groups
later, but I think this gives me a good place to start.
This also adds a new flag to disable running completions using the old
relevance values. That cuts the time to get data by 1/3 to 1/2.
All off these changes led to a fair bit of refactoring to try to reduce
duplication (both existing and what would have been added if I hadn't
done the refactoring).
Change-Id: I5e8dcbba2c01b3665eb486f183f6ad8014285413
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148002
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The completion handler will merge plugin results with results from the
Dart contributor.
For non-Dart files, or files that can't be resolved, it will still
request completions for plugins.
I've added a test case for both scenarios and adapted the capabilities
computer to include plugin file endings for completion.
Change-Id: Id55c6fe33c84d6255de3e723f2628510baace0e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147364
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov