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>
There was a bug earlier in which we were attempting to use a relevance
table (MethodInvocation_arguments) that was not generated. I thought
the bug was that the table wasn't being generated, so I attempted to
generate the table (in relevance_table_generator). But the table can't
be generated and the real bug was that the wrong contextLocation was
being generated when computing the OpType. So I backed out the earlier
change and updated the generation to generate the right location.
Change-Id: Ifbd2c6c3e11e1e98887108be7eb6d90e90452446
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149381
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: 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>
This adds tracking of how often type parameters are declared and how
often import prefixes are used.
It also removes the code to convert to and from JSON because we don't
need it.
Change-Id: I7f3b19e9f82bd8aa1b327797726839ff63837795
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149121
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Konstantin Shcheglov