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>
This method is (accidentally) not currently being called, but it will be soon. The codegen wasn't using the resolved base-type for the enum when writing the type check.
Change-Id: I025ed5109c70d8916f800295350a3f4eaf8f16f2
Reviewed-on: https://dart-review.googlesource.com/c/94294
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously we were only outputting the validation code if the value was required. This changes it to also validate in the case it's not required, but only if it's not-null.
Without this change, the test that parses `'overwrite': 1` fails (a boolean is expected), but with it, it passes.
Change-Id: Ic4afe1f6a8f78add2385831907b226022b7ecaec
Reviewed-on: https://dart-review.googlesource.com/c/94293
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes a mistake where enum classes were resolved to their base types (string, num) before being output in canParse methods of their containing class. This meant for "restricted" enum types (those that should not allow any value), canParse would incorrectly return true for out-of-bound values as long as they were the correct type.
Change-Id: I44e37a60b49287cf7202d5a578ee9c08cf898078
Reviewed-on: https://dart-review.googlesource.com/c/94280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
We only provide fixes/refactors/assists to clients that support returning literal CodeActions (not just Commands). CodeActions allow us to return a WorkspaceEdit directly without having to encode the action into a command/argument set that is tround-tripped to the client. Supporting CodeActions on the client is relatively straight forward (since it just removes a round-trip and applies the edit directly).
Change-Id: I7f5a8c22e66ac23bcde6d5782bc2eaa6aeb283da
Reviewed-on: https://dart-review.googlesource.com/c/94221
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Previously we assumed enum classes could only be the values specified in the spec, but this was not correct - newer clients may know about values that we did not know about at the time we shipped(/last regenerated).
This makes the default for an enum class to support any class (avoiding deserialisation failures when new clients send newer values), and opts-out for those where the spec is explicit that the value set is fixed.
Also opened https://github.com/Microsoft/language-server-protocol/issues/686 for clarification that these "fixed set" values are explicitly intended to never be extended, or whether this is accidental.
Change-Id: I6243fc91c14ec0fa5622d3f6f29bf77cadf7da64
Reviewed-on: https://dart-review.googlesource.com/c/94220
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Sometimes there is no difference between 'relevance' and 'relevanceBoost',
for example for enum constants. But for primitive constants, there might
be multiple `double` constants, in different libraries with their own
different relevances. And it would be nice to keep relative relevances
of these libraries in primitive type constants.
R=brianwilkerson@google.com
Change-Id: I3641a4709e09f5c5dd979f5ca8df7b0235c708d2
Reviewed-on: https://dart-review.googlesource.com/c/92623
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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 ResponseError.data field was typed `dynamic` (as in the LSP spec) but this allows us to accidentally put non-serializable classes in it which will result in server errors when we try to send them back.
This change forces them to Strings and it's up to the code constructing the error to convert any additional data to a string first.
In order to catch this in tests, the mocks now force serialisation of all types flowing from the server to the client (this already happened for client to server).
Change-Id: I5d7f322e1a4296b1479468e36d81daebdbb4ab52
Reviewed-on: https://dart-review.googlesource.com/c/89511
Commit-Queue: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The README was missing some methods (recent additions?) and also not quite in the same order - this fixes that. Also re-generates the classes based on current spec (mostly comments updates, but also non-nullability for `targetSelectionRange`.
Change-Id: I0dd4e24daf51b659783058362339550ec46fa1c8
Reviewed-on: https://dart-review.googlesource.com/c/89641
Commit-Queue: Danny Tuppeny <dantup@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Jaime Wren