The tests in analyzer_cli and analyzer_plugin imported
analysis_server, resulting in warnings when publishing
analyzer_plugin. combining these tests all into analysis_server
shares more code and avoids the warning.
Change-Id: I519f67872500e93e399c5c3d2aeddf781f07602c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149610
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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>
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>
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>
This is a reland of 604a366065
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
Change-Id: I917d3056322d74766bdf376a3e28871ad5b66cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147980
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 604a366065.
Reason for revert: Breaks google3, see b/156414355
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I688a3779e7ccaf85a28dc4d6f5ccf23596109519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147900
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Prior to this change, running `dart --observe foo.dart` would result in
the DartDev flow being bypassed. While `dart foo.dart` will continue to
bypass DartDev and be run directly, running either `dart --observe
<vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
will result in the command being implicitly converted to `dart run
--observe <vm-flags> foo.dart`. This is required for all standalone VM
instances to run against DDS instead of the VM service directly.
As usual, the DartDev flow can always be bypassed by providing the
--disable-dart-dev flag.
Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@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