Maybe? With an explicit type check we don't try to make an impression
that anything more happens here, e.g. for type parameters.
Similarly, for https://github.com/dart-lang/sdk/issues/36697 we would need to introduce `InvalidType`, which is not `DynamicType`. And so, `DartType.isDynamic` should not return `true` for `InvalidType`, it is not a property that various types may have, and should be replaced with explicit `is DynamicType`.
We also have `UnknownInferredType`, but it should never leak to clients.
Change-Id: I302b06355143d97bb52922c805dbad585a522e0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
I doubt that this will have any significant performance impact, but it
seems wasteful to invoke all of the 'generalized' visit methods when
the only important one is `visitNode`.
Change-Id: Ie574d1456a4cccb26090c36f7f6340445bba4006
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287160
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
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>
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 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>
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>
Konstantin Shcheglov