This adds quite a lot of information though, because we send many
strings.
Before: 20686 characters.
After: 55345 characters.
Theoretically we could do better, and send information about existing
imports only once as well, so when the user continues typing in a
single file, without touching imports, we don't send any new data
about imports (maybe just a confirmation that it is still the same).
But I'm not sure if this is a worthwhile optimization.
Actually, even included suggestion sets have similar property - they
don't change for a given file, unless there are changes to other
libraries which we might want to include.
R=brianwilkerson@google.com
Change-Id: I2f55e2dc85508849146aa39eb279beabaec937c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103561
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change adds a new, experimental completion domain request
`completion.listTokenDetails`. Its purpose is to allow
other programs to observe and make smarter decisions contingent
upon analyzer's internal knowledge of a Dart program.
Bug: 36083
Change-Id: I5ab477221efeac076eccc873a29cf6feae91052e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95100
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
interest in receiving not yet imported code completions from specific
packages and libraries.
The design of this interaction aims to avoid forcing analysis server
to send every public symbol from dependent packages at every completion.
Instead, clients express interest in certain packages and/or libraries
and analysis server will notify with the entire set of symbols for
each of them only once. Then it is the client's responsibility to save
these pre-computed completions in memory, and analysis server can
instruct the client on how to union them with the base set of completion
suggestions at code completion time.
Bug: https://github.com/dart-lang/sdk/issues/35680
Change-Id: I42c6fddc5d8daa2b546daa81456c0992e3ef547d
Reviewed-on: https://dart-review.googlesource.com/c/90125
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL extends the dartfix protocol to allow specifying which
fixes should be applied. In summary:
* includedFixes - list of fix names to be applied
* includeRequiredFixes - bool indicating required fixes should be applied
* excludedFixes - list of fix names that should not be applied
Given that the client can specify the fixes to be included/excluded,
then the dartfix cmdline help text should include the list of known fixes.
Rather than hard code this in the dartfix client, a new edit.getDartfix
request has been added to return the list of known fixes.
Change-Id: I319f6f405a5d29757bf28b70b778a449f901bbef
Reviewed-on: https://dart-review.googlesource.com/c/91700
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The goal is to provide clients (specifically VS Code) with API that
is fast, and can search top-level and class member declarations.
I'm not sure whether we want ElementKind, it has kinds that we will
not use, e.g. I don't think we will return local variables or
parameters.
It would be probably still a lot of information, maybe we should use
single string table in response?
R=brianwilkerson@google.com
Bug: https://github.com/dart-lang/sdk/issues/29510
Change-Id: Ie31bb398a08d462c1cb08c7d82c4443c0c09932a
Reviewed-on: https://dart-review.googlesource.com/42105
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson