This way, instead of implicit result that the given node is a
SimpleIdentifier and requiring a cast in the client, or a
PrefixedIdentifier - so we have to check whether it is one or another
again; we now prove the result by returning the actual value, not
just a flag.
Change-Id: I65f0a21e5d3c1e7be06e621a0f7fb6a5e6b2db2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232780
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
As we discussed some time ago, it is not clear to me where some
tests should go. Here, I put it into "location" tests, and checked
locations that seem strongly associated with the enum - its header,
its body; including the `WithClause` on the enum.
It is less clear where tests for completion inside the header or
the body of a method inside of an enum should go. I initially
planned to put them into `declaration/enum_test.dart`, but now
starting to doubt. The tests there are currently for using an
enum from outside.
Change-Id: Ife091f82bbb0ad1f26df984be42aa93a78595816
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232421
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
This assertion is not sound and needs removing, but that requires additional changes to ensure callers (including plugins) provide line/col information. This change reduces the chance of it triggering (by avoiding it being used for context messages) in the meantime.
Change-Id: I73c861b69a795212ae0d59e30da6aa6bdd1bb3af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232082
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I was thinking about unifying these two codes for documentation purposes,
but then I wondered whether we might not want to unify them for reporting
purposes too. The reason I think it might be better to unify them is
because (a) they really represent a single problem (missing required
arguments) and (b) we were previously reporting the same problem multiple
times.
Change-Id: Iecf2865e67d61b03a1e1f56781e94e283d2a08e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232022
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
* many super-parameter codes can have a fix of "remove 'super.'"
* many constructor-tearoff codes can have a fix of "remove type
arguments"
* did not evaluate the FfiCodes or PubspecWarningCodes
Change-Id: I3421f226ec88621d9927970cb607e13577c8f234
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This improves time to compute completion metrics from 61 to 48 seconds.
We used to spend 21% of all time in `[Stub] InstanceOf`.
Now 2%, unfortunately it does not show back pointers.
Change-Id: I3c6c62cabfa86bac138d95d4830b605693e086d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/230580
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
There are quite a few TODOs left in the code, and I'll address them in
future CLs, but this appears to be consistent with the behavior of the
previous implementation and finishes the majority of the refactoring
changes.
Change-Id: I68093f6ac115f8b8b9b10bf93239fe4e2b9c6390
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229660
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
A few tests added, mostly removing CompletionSuggestionKind.INVOCATION
because it is set just for any available declaration by the completion
driver, but this is not what we use for local elements and the new
protocol.
Change-Id: I87da134fd94da75005a98e17e81f43ee56451baf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is the first of multiple smaller CLs to refactor `ElementMatcher`.
I was starting to fix a bug and realized that the current implementation
allows the number of components to be out of sync with the element kind.
The primary goal is to prevent that by eventually merging the methods
`_componentsForNode` and `_kindsForNode` into a single method
(`buildMatchersForNode`).
In the process I realized that we can sometimes match either a top-level
declaraation or an instance member from a superclass, and that means
that we need multiple matchers (otherwise I think the number of
components will continue to be out-of-sync with the element kinds).
This CL also includes the failing test that started the whole
investigation into refactoring this class.
Change-Id: I0c3a56f29f0f6c6d0cad6ac80145b26201931518
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/228722
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Brian Wilkerson