Also:
- fix order of arguments to HBoundsCheck
Change-Id: I4dbcca67dd89f3048a22315d8db2fa862d810774
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213620
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This hint message doesn't take any arguments.
Change-Id: Idc2546901b3dcbbbb45356628028f1ac08d71c7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213730
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This error message was previously reported by the analyzer's parser,
which presumably supplied an argument describing the modifier. It is
now reported by the shared parser, which doesn't supply any additional
information. As a result, the error message was showing up for the
user as "The modifier '{0}' can't be applied to the body of a setter."
(with a literal `{0}` visible to the user).
Changed the error message text to match what the CFE reports. There's
no real need for the message to describe the modifier since the error
message location is the modifier itself.
Change-Id: I538d49c1b693fe6cfb190f584bb5c9ab5cd3cf39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213732
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These error messages don't take any arguments.
Change-Id: I1818dea02801b3f14f2db0c74841071d8457365a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213728
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This error message doesn't take any arguments.
Change-Id: I12cfe2a079eb3c6f81976e1ce451ce6ab6d0c47a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213731
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The error message text is:
Generic function types can't be used as type parameter bounds
And the correction message is:
Try making the free variable in the function type part of the
larger declaration signature
There are no placeholders in these messages to accept arguments, and
there's really no need for any (since the location of the error is the
offending type), so just remove the argument.
Change-Id: I0ea653d7085782f924c63fbdb0e19ac66f04808a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213700
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This error message doesn't take any arguments.
Change-Id: I5ff2e43c6d6877189ad8cf7cefded72b4867a309
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213727
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The message for this error code doesn't accept any arguments, so
there's no reason for the test to provide any.
Change-Id: I6306cead7865704c9074dd0dc2a1bc1aacaeda16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213724
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Some of the error messages reported by TypePropertyResolver.resolve
require arguments, others don't; this change ensures that we pass
arguments only when they're needed. This should pave the way for
adding assertions to make sure the proper number of arguments are
supplied when instantiating an error message.
Change-Id: Ic94a4ff7ee2f7845a693b91f8a9231570e0cf4c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213723
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
None of the error codes passed to this method require arguments, so if
this method reports an error, it shouldn't supply any arguments.
Change-Id: Iadcf2652bd46420944cbdffcc2e69415c07f00fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213725
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change-Id: Ic029cf3c823f0b226d41e75513f28632bde52194
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213729
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
INVALID_USE_OF_NULL_VALUE doesn't take any arguments, so we shouldn't
supply any.
Change-Id: I2b78277d754a5d009800927a50cff20c771c162f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213726
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL removes async markers where await wasn't used.
In a few cases this also meant the ability to make the procedure not
return a future at all.
Also - at least on the VM with my benchmark run on my PC - returning
new Future.value(whatever) in a non-async procedure is faster than
returning whatever in an async procedure.
TEST=CI and existing tests.
Change-Id: I4ba888313c87de76bb0ca02c19eb1ab45f168a85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213480
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously we had identified this error with the analyzer error code
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR, but
they're not the same error at all. As a result, code like this:
var x = new a.b.c<C>();
would lead to the bogus analyzer error text "The constructor '{0}.{1}'
doesn't have type parameters." (with the placeholders "{0}" and "{1}"
visible to the user).
With this change, the error text is the same as that from the CFE: "A
constructor invocation can't have type arguments after the constructor
name."
Change-Id: Ib69d1ff8f7089e59b71d2dcd9a8ec51edffd94dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Allows for tooling (e.g., DAP) to spawn their own DDS instance without
having to disable the CLI.
Fixes https://github.com/dart-lang/sdk/issues/47059
TEST=pkg/dartdev/test/commands/run_test.dart
Change-Id: Ie9a4832d424edae67f32560399d3b0a6ca9f1dc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213660
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Such long jumps may occur due to Out Of Memory exceptions.
TEST=run test harness with low heap limit
Change-Id: Ifc8d062d4325ea3cdb4ea1f1ad1877f2dc83229e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213534
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This improves discovery, refactoring, etc.
I did not change any locations which would have required interpolation,
or tests which refer to a String immediately nearby (in tests).
Change-Id: I8479fd7822713e878e56fdf5ec35969492049333
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213580
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
TryReleaseReservation could insert an element into the freelist before the concurrent sweeper visited that page it was on.
TEST=run test harness with low heap limit
Change-Id: I482c820756ea3dbfe6d16c8bdef998e843c576dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213536
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This test was flaky and started timing out consistently on
vm-kernel-precomp-tsan-linux-release-x64 bot.
It times out even if marked 'Pass, Slow' in status file.
Change-Id: Id3af3fafd0939e61b5efd3adcedc966548ac8bb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213623
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
TEST=run test harness with low heap limit
Change-Id: I75d3b2e8461bcf99cc41eb3ad76173bc1976bbd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213538
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
TEST=run test harness with low heap limit
Change-Id: I8084c50c3aab1c0cbfa32bbcc5df100abe4211bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213537
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change-Id: If3e7d74af72c4d3c4e533d2c3dcd880c4f2b5bf1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213622
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In legacy code `int v` was implicitly `int|Null v`, so `v is int` could
be useful (although probably should be `v != null` then). In null safe
code, we cannot have `Null`, so we can report a hint.
Change-Id: I60dc0791c6b8346d924fd13b1d2ce3fcceb22d32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190360
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Since bbefc05748, both serialization formats in the VM are based on clustering. The distinguishing feature of the older clustered serializer is that it represents apps/programs rather than messages.
TEST=ci
Change-Id: If3185c21c6aadeec61a940b12ba23d17f2752761
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211501
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
