These cases are collected sorted and printed back out to help us improve the context type algorithm, that is we may choose to in completion locations 'var i = ^', to assume that the user will be entering an int type.
Change-Id: Ia3e4663b2cf1614935ff49a4ab10299db0dc909d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151783
Commit-Queue: Jaime Wren <jwren@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The values are now only printed when `verbose` is enabled, and are
sorted based on how mig an impact completions in those locations are
impacting the total.
Change-Id: I913f82e57cf0a97d3465b0b41d9431ca3cf56e30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150262
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: 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 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 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>
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>
Konstantin Shcheglov