* 99% of these are `Future ` --> `Future<void> `
* There are some `test_` methods which declare a return type of `Future` which
is non-idiomatic, I think, but in order to create a pragmatic consistency, I
added `<void>` to the few test methods in these libraries. Later if we
desire, we can remove all of the return types.
* Also a few `Completer ` --> `Completer<void> ` and
`Stream ` --> `Stream<Object?> `
* There are many remaining cases in `lib/`
Change-Id: I41cd51bab6886788e15ac7065dd21e95e789d09f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@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 should allow doing partial migration, specifically protocol files,
which are imported by other libraries, but are a small library cycle
that does not import much outside of it.
Change-Id: I904c05d6d5b444ee9a9dbd1f7ada12aabdcc5165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193583
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This required some changes to analysis_server, since analysis_server
used to have its own version of pumpEventQueue(). Since
pumpEventQueue() is now provided by the test package, I've removed
analysis_server's version, and I've updated some of the call sites to
pass in "times: 5000" to replicate the old analysis_server behavior.
This also required some changes to analyzer, since the fail() method
is now marked as @alwaysThrows, so no code may follow it without
producing a dead code hint.
Change-Id: Ie5ef3a5cc685c18da02de699e59f63f3bb8865f7
Reviewed-on: https://dart-review.googlesource.com/32683
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Brian Wilkerson