I wasn't comfortable with the previous approach of fixing one
contributor at a time, so I tried handling a single location all at
once. I think it worked better, and might be easier to review.
So what that means is that I think the tests and changes cover
everything that needs to be done for object patterns. If you see
anything I missed, please let me know.
Change-Id: Ia4a5e8ed1cb7c1f68a96d5856165b239126ddfd4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280124
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This shares a cache for mapping Elements to their public LibraryElements across each snippet producer, and also skips snippet producers that produce snippets that won't match any typed prefix.
Change-Id: I6b64b3c55f1030a5eaa7ca1afdcd6c416e4baa08
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273962
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/sdk/issues/50542
One primary principle is keeping the cost for _most code_
extremely low. Most code does not have an `examples/api`
directory. Most comments do not have `{@tool`.
Looking for directories on disk is expensive. Walking tokens
in comment text is cheap. So we can pay the price of walking all comments, prowling for `{@tool` text which we won't likely find,
and skip the work of looking for `examples/api` in _all_ parent
directories, until we find a comment with `{@tool`.
Don't check if `$parent/examples` exists before checking if `$parent/examples/api` exists. We don't care if `$parent/examples`
exists.
Don't create an `AanlyzerConverter` instance for _every element_
in a compilation unit while we are editing it. Instead, refactor
some of the `AnalyzerConverter` methods to be extension methods.
Change-Id: I812a1a435ee075e921782c1a57e9ed77325f9387
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271863
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
+ convert LSP folding tests to use TestCode parser.
A change in VS Code means two folding regions are no longer allowed to end/start on the same line (the second range is silently dropped). This truncates folding regions if they end on the same line that another starts to end on the line before (but only if a client only supports line-folding mode).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4121.
Change-Id: Ic26f58f84c44a01ae5157c336ed0f207d1c0eeb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261900
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This fixes a few minor issues:
- Setting a new selection position did not remove a previously set selection range (which could result in a mismatched offset/length due to how the resulting change merges the position/range)
- Setting a new selection range did not update a previously set selection position
- Inserting new changes before a change that sets a selection range only updated the selection position, not selection range
- Setting a selection range/position after another change that inserts only updated the selection position to compensate and not the selection range
These issues led to cases where selection ranges could be incorrect, or even overlap with linked edit groups that could cause errors that caused code action requests to fail.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4184
Change-Id: I43e2a8361c97b2eccb2d6b426a75eda5cc811e06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261682
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds a test for the dartdoc "See code in examples/api..." navigation in the analysis_plugin, and changes things so that it doesn't walk the directory tree to find the examples directory more than once per compilation unit.
Change-Id: I1938396b160ca2d21b08214f79fb1c7ddbf6a388
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261281
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Greg Spencer <gspencer@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This also introduces CompletionResponsePrinter, which I'd like to use
instead of fluent APIs. At some point I decided that using easy to
produce, and easy to update expectations is better. Fluent API based
tests are too magical and require too many helper extensions. Also,
with textual dumps full actual results are visible, so it is easy to
compare them with expectations.
The missing key part for using textual dumps in completion tests, that
I realized only recently, was filtering. So, we don't need to dump
every available type, but we can focus on specifically named, or
specifically filtered, entities.
And configuration for `withX` flags lets us enable including features
that are interesting for a particular test suite.
Change-Id: I4a7f7ec99ed202333cf56cd3bb0dfec9ae5c39f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
I don't think that there are any other highlight kinds we're going to
want to add, but if you can think of any please let me know.
I'll add code to actually associate the kind with record literals in the
next CL.
Change-Id: I15922984d96c2d0c7d97ea3f3832a95a68172968
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256524
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Unfortunately my idea about checking for specific `DartType` subtype,
and only then asking for the element is too punitive. It almost
works in google3, but the amount and the kind of changes I had to
do make me realize that we should keep `get elementX` in `DartType`.
I guess this is the same as we had in AST when `get constructors`
does not make sense for mixins (?), but works for classes and enums,
and it is easier to pull it into the superclass.
Change-Id: Ibc4fac0b95d63748fa65de96d29300f477fdfc76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254482
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Brian Wilkerson