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>
Fixes failing post-submit Windows tests,
and causes the examples/api IDE navigation results to return absolute paths.
Change-Id: If6d1ca9848644b78ff6f8e9549b84df7139b7ffc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261801
Auto-Submit: Greg Spencer <gspencer@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@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 one of the issues noted in https://github.com/Dart-Code/Dart-Code/issues/4181, where all example regions would be returned for a code block instead of only those that matched the requested region.
This was because the code that handles comments didn't go through helpers in `_DartNavigationCollector` that does the filtering.
Change-Id: I58931c02f0e4f538c246dc8fc0c3e57895cad5fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261365
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>
While the work is incomplete (see the TODOs), this fixes an exception
that I saw this morning and is, I believe, a step in the right direction.
Change-Id: I6adc0e0df4ea9b64ea0c5d1dcd42a078d30c4a9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258507
Reviewed-by: Konstantin Shcheglov <scheglov@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>
This is necessary to separate `ClassElement`, `EnumElement`, and `MixinElement`. And, in the future, augmentations like `ClassAugmentationElement`, etc.
Change-Id: Iecd2f8707212e53ef56f0e101880c7bab9e5d057
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254104
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For `InterfaceType` keep `element2` deprecated and define
`InterfaceElement get element2` instead. Most changes are because
of this.
Change-Id: I13b888610fc707438c3c97b676f1460e7fc2b040
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253564
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
