The intended use is in benchmarking, to specify a long timeout, so that
the first time, when we warm up, we do necessary one time work,
which would usually run out of budget the first few times. So, the
requests that we do measure are more stable.
Change-Id: I22e870b84dcd6f2ac201c5ec57081c39c6529ea1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220129
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When we resolve partially for completion, there is no fully
resolved unit. But we still know its path, content, element.
Change-Id: I57a21eb764ecd0b4c82ade33ad633bb2cd632b7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 41397cbb9a.
Reason for revert: Actually, we do use it in google3.
Original change's description:
> Remove ServerService.LOG
>
> It looks that it is not used. We have a way to turn it on in
> DartAnalysisServerService.java in Dart plugin for IntelliJ, but
> setServerLogSubscription is not used in the plugin, marked as to be
> used in the Flutter plugin, but actually is not used there.
>
> Change-Id: If851044385100543ec0ff30e02dee3d99f1558e4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219362
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
> Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
TBR=scheglov@google.com,jwren@google.com,brianwilkerson@google.com
Change-Id: If5b807bf40adb8527aa801608fac6b1052adf67f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219382
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
It looks that it is not used. We have a way to turn it on in
DartAnalysisServerService.java in Dart plugin for IntelliJ, but
setServerLogSubscription is not used in the plugin, marked as to be
used in the Flutter plugin, but actually is not used there.
Change-Id: If851044385100543ec0ff30e02dee3d99f1558e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
* Replace `identifier` field with `expression`, which means deprecating
`identifier`, redirecting users to `expression`. For now, `expression`
always returns an Identifier. In a future breaking release, it will
return other CommentReferableExpressions.
* SimpleIdentifier, PrefixedIdentifier, PropertyAccess,
ConstructorReference, FunctionReference, and TypeLiteral are all
CommentReferableExpressions, but support is not implemented yet to
parse CommentReferences with those contained expressions.
Bug: https://github.com/dart-lang/sdk/issues/47444
Change-Id: I1905afecf3878cd7dca6e275ef0a2ab80500eb4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216320
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
I think we don't expect that users will write plugins that use these
types. So, we can remove the indirection.
Similarly, CompletionRequest is also currently de-facto a Dart
completion request, because it has `ResolvedUnitResult result`. I will
fold it into DartCompletionRequest in a future CL.
Change-Id: I2ea1d443ae18535f8c72f785dd1b91cf8d30ffa7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218021
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We give it (indirectly) ResolvedUnitResult, so it does not do any
async operation.
Change-Id: I2d29925fd20ea14bd984e6c3c226de466a03fb39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217824
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We sometimes create it outside DartCompletionManager, and then call
and create it inside again.
Change-Id: Ifa5bd958437a5ea4e2bac65e7800183f915a9a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Follow-up to cb7c932f7b
Change-Id: Ie00e7759880bfc80f7b04a79979325d26607f148
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214581
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Update min SDK to 2.14
Change-Id: I370875b550f5c103560e13697329c1443c036a2c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212880
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I found this while testing a change to the computation of the completion
location in `OpType`. The experiment started producing a completion
location that wasn't previously produced, and that's what led to it being
a key for one set of data but not in the other set of data.
Change-Id: I3938ae68ec61afbef98d9674c7d6377fa4120d4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211100
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
In https://dart-review.googlesource.com/c/sdk/+/191862 we added two new
required fields to `Location`. Unfortunately this was a breaking change
because plugins using an older version of the `analyzer_plugin` produce
location objects without those fields, leading to deserialization failures.
This CL makes those fields optional in order to fix the deserialization
issue.
Unfortunately, the `analyzer_plugin` package was published after the
required fields were added. Making them optional is a breaking change
because the constructor parameters go from being positional to being
named parameters.
We also neglected to update the version number of the protocol as part
of the previous CL. Technically this is also a breaking change for clients
of the analysis server, but given that they had no way to test to see
whether these fields existed they would need to have been written as if
the fields were optional in order to reference them at all, so I think
that from a practical standpoint it isn't a breaking change. That does,
however, raise the question of whether we should increment the version
numbers as part of this CL.
Change-Id: I35fc1f8e950669a3d8dd33cee6b81890261b5c47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206942
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This causes completion failures to be split into two groups: those for
which there was no suggestion and those for which the name was suggested
but the wrong element was selected (as in the case where the correct
element shadows the one that was suggested.
In addition, the both groups of failures are now further grouped by the
location in which they occur.
Finally, failures to complete in hide and show combinators are temporarily
ignored until we can figure out how to complete as if the target identifier
wasn't already in the list.
Change-Id: I1515ad5a8862132b1b77287af45a638649cef7a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203082
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change makes sense to me for a couple of reasons. First, when
editing a correction producer the information about whether it can be
bulk applied will be easier to find. Second, the information doesn't
need to be duplicated when the producer can be applied to multiple
error codes. And third, because the information is in one place we can't
enable a producer in one place and miss enabling it in other places.
This does have the unfortunate consequence that an extra producer needs
to be created for bulk application in order to determine whether it
should be applied at all, and can't be re-used because producers
maintain state. We could consider storing a 'generator' object rather
than a generator function in the map and have the `newInstance` methods
produce those objects, but I'm not convinced that it's worthwhile given
how short lived the extra producer is.
There was also one subtle change that you probably won't see by looking
at the changes, which is that one of the producers was enabled for bulk
application for a lint but not enabled for several non-lint cases. It is
now enabled everywhere. I remember thinking at the time that it should
be fine, but I've forgotten which producer it was, so I can't easily
tell you. If you want to confirm that change I'll be happy to do the
work of figuring out which producer it is and which error codes were
impacted by the change.
Change-Id: I2010d777f727472c0d307a6948b84d37491e2b17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/202600
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
