The code to check the element kind was not being used in a few places
because (a) the generator wasn't always generating a table when it
should and (b) the key for the table wasn't always being set when
creating the OpType. Both of these issues have been mostly addressed.
That required re-generating the element kind tables.
There were several places where context type information wasn't being
used when building suggestions. This has been fixed for all the places
I'm currently aware of.
There were a couple of places where the context type wasn't being
computed where it could have been. I have fixed the places I'm aware of.
Context types were not being computed anywhere because of a bug that
has now been fixed.
There is now one place that computes and caches the context type, which
should improve performance slightly.
I also removed some dead code that I discovered in the process of making
the other changes and cleaned up a couple of places in the code that
were suboptimal.
Change-Id: Ieae8dcc71b986841be3078d6e0b3a653c35384b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148237
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Sorry about the size of the CL. I can split it up if you'd like.
In order to do this I added a listener to SuggestionBuilder so that we
could capture the data as suggestions are being built. If it turns out
to be a performance problem we can remove it before shipping it, but it
should only impact the new relevance path, which isn't being used yet in
production.
This splits the "worst" and "slowest" (formerly "longest") results into
three groups. I might find it useful to split them out into more groups
later, but I think this gives me a good place to start.
This also adds a new flag to disable running completions using the old
relevance values. That cuts the time to get data by 1/3 to 1/2.
All off these changes led to a fair bit of refactoring to try to reduce
duplication (both existing and what would have been added if I hadn't
done the refactoring).
Change-Id: I5e8dcbba2c01b3665eb486f183f6ad8014285413
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148002
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is a reland of 604a366065
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
Change-Id: I917d3056322d74766bdf376a3e28871ad5b66cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147980
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 604a366065.
Reason for revert: Breaks google3, see b/156414355
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I688a3779e7ccaf85a28dc4d6f5ccf23596109519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147900
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Prior to this change, running `dart --observe foo.dart` would result in
the DartDev flow being bypassed. While `dart foo.dart` will continue to
bypass DartDev and be run directly, running either `dart --observe
<vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
will result in the command being implicitly converted to `dart run
--observe <vm-flags> foo.dart`. This is required for all standalone VM
instances to run against DDS instead of the VM service directly.
As usual, the DartDev flow can always be bypassed by providing the
--disable-dart-dev flag.
Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
The completion handler will merge plugin results with results from the
Dart contributor.
For non-Dart files, or files that can't be resolved, it will still
request completions for plugins.
I've added a test case for both scenarios and adapted the capabilities
computer to include plugin file endings for completion.
Change-Id: Id55c6fe33c84d6255de3e723f2628510baace0e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147364
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL enables us to have different crash reporters that report to
different backends, this will be useful if we report plugin errors to
staging and server errors to prod.
Currently doing this with server errors so that we can make the switch
over to prod incrementally. For the time being, the staging backend will
have our whole crash history, and continue to get new crashes. Reports
and dashboards can switch over to the prod backend as we get enough
history for those reports to be useful, and when we have switched
everything over we can stop reporting to staging entirely.
Change-Id: Ie29b4e05c89fd57faf1487a2c2eba3701fc319d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145922
Reviewed-by: Devon Carew <devoncarew@google.com>
At this point I'm mostly interested in getting your feedback on the
general approach of making the fix processor be table driven. If you
agree that it's a good direction, then I would actually propose adding a
static method to each of the producer classes that looks something like
static AddRequiredKeyword generator() => AddRequiredKeyword();
and updating the map to contain references to those static methods
(rather than local closures), such as:
CompileTimeErrorCode.MISSING_DEFAULT_VALUE_FOR_PARAMETER: const [
AddRequiredKeyword.generator,
],
Doing so would make the code in FixProcessor slightly cleaner, and would
allow the tables to be constants.
Change-Id: Ifdd8a4d82c6ab83aea0929dc9c8a4dcbce271e6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146064
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Without this, it's possible for a unit test failure to result in a
preview server remaining open, which can prevent test execution from
terminating.
Change-Id: I8a11056da5bea003dfa46e3871a241e8f5ce8cc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145440
Reviewed-by: Janice Collins <jcollins@google.com>
Brian Wilkerson