The `AnalysisDriverScheduler` already keeps timings of all of its operations (in `accumulatedPerformance`), but they're not easily accessible to users and might help track down some kinds of performance issues.
This adds a new page to the diagnostics server that shows the timings, as well as a reset button to clear them so they can collect numbers just for a specific operation(s).
It involves some tweaks to the server to handle `POST` (because we shouldn't really use `GET` to mutate anything).
Change-Id: Ia49d471aaa1637a0c978f75569556b26982367d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388561
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Most DTD tests are currently skipped because we're not currently exposing the LSP handlers, however I temporarily added them and verified with this change that those tests pass (both success and error requests).
Change-Id: I001b7b07c99be18a3711a434bdd081a631e4b4c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383842
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
If analysis failed due to an exception, "dart analyze" may still report "no issues found" because it didn't get any server errors.
It didn't get server errors for a number of reasons:
1. Analysis errors were silent (see https://github.com/dart-lang/sdk/issues/39284)
2. `server` in ErrorNotifier was always `null` because the code that set it did so too early
3. `ErrorNotifier` was never added to the instrumentation service, so never got called anyway
Additionally, "dart analyze" printed "No errors found!" even if server errors occurred (as long as the server didn't crash).
This change fixes up the server reference in ErrorNotifier, adds it to the instrumentation service and uses a new flag ("--disable-silent-analysis-exceptions") to allow opting-in to getting analysis errors to the client. It also updates "dart analyze" to not print "No errors found!" (and to not use a 0 exit code) when server errors occur.
Because this change "fixes" ErrorNotifier, it's possible that with this change clients will now get additional error notifications (non-silent exceptions that were being dropped previously) which could result in users seeing more errors - but presumably errors that should have been reported before anyway.
Fixes https://github.com/dart-lang/sdk/issues/49931
Change-Id: I4948117c78b8f382550b7641076de443250bba6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358902
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In order for CorrectionProducers to be used in analyzer plugins, we
need to access DartFixContributor which needs to compute fixes via
FixProcessor. So both DartFixContributor and FixProcessor need to be
moved into analyzer_plugin (eventually). For now, to support
prototyping, I am moving FixProcessor to its own library, and
separating all of the built in mappings (from diagnostic to producer
generators).
I think this separation actually stands on its own as being tidier,
simplifying fix_internal.dart, and separating code from data, as it
were.
Work towards https://github.com/dart-lang/sdk/issues/53402
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try
Change-Id: I3b4fadc7ed94c23597d72bef7dcd832380d34e9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345561
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- Adds a new flag, `--suppress-analytics` to the `dart` command to
disable both the unified and the legacy analytics for a single
session while deprecating the existing flag, `--[no-]analytics` used
for disabling the legacy analytics on a single pass.
- Pipelines the flag from `dart` through `dart analyze` and `dart fix`
to the execution of the analysis server.
- Updates all applicable uses of `dart analyze`, `dart fix`, and the
analysis_server binary entry points in the SDK to disable analytics
for the test infrastructure.
Bug: https://github.com/dart-lang/sdk/issues/49445
Change-Id: I1302cad7e04b21454aa7d9e8ee72a876b231377d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287661
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Janice Collins <jcollins@google.com>
This clears all of the implicit `Future<dynamic>` types in lib/.
Also a few `extends XyzVisitor<(implicit) dynamic>` are made into
`extends XyzVisitor<void>`.
Also a few raw Stream, StreamController, and Completer types.
Change-Id: I2471cc56d2d2d0545e5e103fff3189e745a54b49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287245
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Before this CL, typing in a big file in IntelliJ on Windows could lead
to longer and longer latency (read: taking longer and longer from you're
finished writing and the code is error free until the editor doesn't
report an error --- I've reached 40 seconds for a simple print statement
in my testing).
This is caused by a number of things; this CL fixes the issue by
receiving data from stdin in an isolate.
Background:
* The IntelliJ plugin sends the whole file on every change in a file.
Files can be big though, and e.g. `ast.dart` in the kernel package is
almost 500 kb.
* The IntelliJ plugin sends the data in chunks of size ~8192 bytes.
* On Windows (but not Linux) it is also received in chunks of that size.
* Darts `LineSplitter` is currently quadratic in behavior
(https://github.com/dart-lang/sdk/issues/51167) (to be fixed with
https://dart-review.googlesource.com/c/sdk/+/280100)
Even with the fix of `LineSplitter`, when editing `ast.dart` in IntelliJ
on Windows, (as long as one is typing fast enough) we'll create a longer
and longer queue of messages (with more and more latency).
In testing I reached ~40 seconds of latency, i.e. after I was done
typing and there were no more errors it took ~40 seconds before the
Analyzer and the editor agreed.
I think what's happening is something like this:
* You type a character in IntelliJ in Windows.
* IntelliJ sends two requests: Updated content (the whole file, i.e.
lots of data) and "give me completions".
* You type another character (I seem to type one character every ~150 ms
when typing) and it sends two new requests.
* When receiving is slow it processes everything. So it updates the file
and marks the file for being analyzed. Then it processes the
completion requests which "forces" the file to be analyzed. This takes
more than 150 ms, so it gets behind. More and more so for each
character typed.
Receiving in an isolate means that once the main thread receives
(now via a `ReceivePort`) it receives more data and can now skip some of
the completion requests meaning that it doesn't analyze the file for the
"intermittent" updates.
Change-Id: I43507412abfddcfb903d90d86226172b291bdb47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280321
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL keeps slow (500+ ms) requests around for longer (to a total of
1000 of them), saves the start time of the request and prints a little
more on the details page.
The overall idea is that having a record of slow requests is better
for debugging performance related issues than only having the newest
50 requests which basically requires one to "catch it" as it's being
slow.
Currently the 500 ms deadline for "slow" and 1000 requests saved was
just grabbed from thin air; we can adjust them later if needed.
Change-Id: Ib0d6e1fc2daad215d8745249abdc82f831a83785
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279087
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I wanted to be able to plug in different kinds of analytics reporters,
and that's still a goal, but with the desire to make it possible for
users to see what data we are collecting I needed to change the level
at which reporters are plugged in.
This CL doesn't change the behavior of the code, but it does split the
classes out into separate files and collapse the AnalyticsManager class
and its subclasses into a single class, requiring that different
reporters be implemented by implementing the Analytics class instead.
Change-Id: Ia98ff225f97ae747d89c61fe98f520ce0b5e9961
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249943
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
In order to avoid passing several pieces of data through several layers
of the API, this change passes the analytics manager down. This means
that we're creating the manager earlier, but I think it keeps the code
cleaner.
Change-Id: I096e416c1aa445f5f7382ae666b3d02d0abf0a0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246320
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny