This CL simplifies the grammar rule for a primary constructor and the
place where it's used (`classNamePart`) - the proposal no longer uses
a version that cannot have the modifier `const`. Also, it de-inlines
`typeWithParameters` for consistency and brevity.
Change-Id: Idbd2182a6a29256d61c617c9eb2f631213cb3234
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/455400
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Previously these were being run with the standard "pkg" unit test suite.
All the other backends have their own unit test suite so this introduces
one for dart2wasm.
This ensures the tests run with the correct fileset (including d8).
Change-Id: I29cd0048a4d6731da3a20110f6e496fe7da0c3b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454760
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The spec_parser grammars have previously made a distinction among the
different kinds of members that a class, mixin, extension type, etc
could have. This is not very useful, though, so this CL changes the
grammar such that they all just contain a sequence of general member
declarations `<memberDeclaration>`. It is then up to non-parser based
error checks to prevent whatever should not exist (e.g., until we add
constructors to extensions it is an error to declare a constructor in
an `extension`, but this will be an ad-hoc check rather than a syntax
error).
Change-Id: Ifca2713af86eb3f569732ebef844135b772a5465
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454280
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
- Added running `dart pkg/analyzer/tool/api/generate.dart` to prevent
people from finding out they have to update the `api.txt` only when they
run try-jobs.
- We should also update
`pkg/analyzer_testing/lib/experiments/experiments.dart` at this point. I
always forget and spend time wondering why my tests aren't working. And
this is probably the most ideal step to do this at.
Change-Id: I68a33a39d7b5360e586f7aa17f223cf9d9014885
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453644
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Kallen Tu <kallentu@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This adds a wasm binary reader that produces an `ir.Module`.
We also make a few changes to existing code
* Represent the import section with an `ir.Imports` object (similar to
`ir.Exports`, `ir.Functions`, ...)
* We make a bunch of data structures allocatable in uninitialized state
(the fields being usually uninitialized `late final` fields) where the
deserializer can create those objects and then fill in details later.
=> This comes partly due to the way wasm binaries are structured
themselves: The "data count" section comes first so a reader knows
how many data sections there will be, then the "code section" can
refer to those data sections. Then afterwards the actual "data
segment" comes that fills in the data of the section.
* We make names consistently optional: Wasm objects don't have to have
names, so the names should be optional, so we make them `String?`. We
also make them non-final as that's consistent with other names.
* We make the `ir.Types`, `ir.Functions`, ... objects have `operator[]`
and the index used is the same index used e.g. in wasm instructions.
* We make static constants for section ids and custom section names.
Issue https://github.com/dart-lang/sdk/issues/60928
Change-Id: I5394d6b82cf4dc68d24cea1dee66c5b33eb2f60f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452144
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
When the shard count is greater than the number of machines in the pool, shards are guarenteed to wait, increase latency relative to a lower shard count.
Change-Id: I1fd61a59837b767748c13120dec30ca6eb352f28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/450946
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Make it available on the stable branch.
Fix the version numbers for when it was enabled. (3.9 as experiment
enabled is not entirely correct, as the experiment was not available
on the stable channel in 3.9, only on betas of 3.9.)
And disable passing data assets under the same experiment flag.
Note: It seems that it was accidentally still marked as 3.9 and then
got swept up in https://dart-review.googlesource.com/c/sdk/+/443803.
TEST=dartdev native assets tests
Bug: https://github.com/dart-lang/sdk/issues/50565
Change-Id: I4c44ad22e32673d6a951017d0cf6d3374dd20429
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449803
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* Shard dart2js modular tests (and decrease the shards of the
unit tests)
* Remove folders we look for dart files in --- the remove folders
doesn't contain any anyway and would have to be copied if keeping
these lines.
* Fix sharding, previously trying to shard in 2 shards would only allow
you to run ~50% of the tests:
```
$ out/ReleaseX64/dart-sdk/bin/dart pkg/compiler/tool/modular_test_suite.dart -nweb-unittest-asserts-linux --verbose --use-sdk --shards=2 --shard=0
Error: shard should be between 0 and 1, but got 0
$ out/ReleaseX64/dart-sdk/bin/dart pkg/compiler/tool/modular_test_suite.dart -nweb-unittest-asserts-linux --verbose --use-sdk --shards=2 --shard=2
Error: shard should be between 0 and 1, but got 2
```
This has been corrected to allow from `1..n` for `n` shards to fit
with what the testing system sends when specifying `shards` in
`tools/bots/test_matrix.json`.
For previous try runs I extracted this:
Build 60615:
Shard #1: --- Total time: 04:27 ---
Shard #2: --- Total time: 05:19 ---
Shard #3: --- Total time: 04:23 ---
Shard #4: --- Total time: 10:29 ---
=> A total of 24:35 --- combined finish of 10:29
Modular tests: 32:19
Total bot runtime: 35:48
Build 60614:
Shard #1: --- Total time: 03:57 ---
Shard #2: --- Total time: 05:18 ---
Shard #3: --- Total time: 05:21 ---
Shard #4: --- Total time: 05:34 ---
=> A total of 20:10 --- combined finish of 5:34
Modular tests: 29:41 secs
Total bot runtime: 35:55
Build: 60613
Shard #1: --- Total time: 03:56 ---
Shard #2: --- Total time: 05:15 ---
Shard #3: --- Total time: 04:32 ---
Shard #4: --- Total time: 05:34 ---
=> A total of 19:17 --- combined finish of 5:34
Modular tests: 33:39
Total bot runtime: 38:51
With the new sharding I'd estimate that the unit tests and modular tests
would have finished in less than 13 minutes, making the bots finish in
~17 minutes, ~20 minutes and ~19 minutes instead.
The try-run with this ran in 17:06
Possibly a follow-up could do more stuff on the "main bot".
Change-Id: Ie5c96206deb9c0c6db3385bbca04ae6f4eab4c3a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/448381
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Call __tsan_func_entry/__tsan_func_exit in functions that use __tsan_read/__tsan_write or call other functions. Call __tsan_func_exit once per frame when unwinding for exceptions. Do so only in AOT, since TSAN won't be able to symbolize JIT functions anyway.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/61352
Cq-Include-Trybots: luci.dart.try:vm-tsan-linux-release-arm64-try,vm-tsan-linux-release-x64-try
Change-Id: Ie52c978c25664d78b834e9b72ecf7eb2a12cc2ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444181
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This is a follow-up to
https://dart-review.googlesource.com/c/sdk/+/444921, which renamed
analyzer error codes from SCREAMING_CAPS conventions to camelCase
conventions. That CL left a few deprecated error codes in place
because they were referred to in
`tools/verify_docs/bin/verify_docs.dart`, and those references
couldn't be fixed in an automated fashion.
This CL cleans up the references in `verify_docs.dart` to use the new
camelCase constants, and removes the deprecated SCREAMING_CAPS
constants that are no longer needed.
Change-Id: I6a6a69644eb8cfe7841d7582fd520f081010544d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445106
Reviewed-by: Moritz Sümmermann <mosum@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A temporary script is added,
`pkg/analyzer/tool/messages/rename_error_constants.dart`, which will
rename every error code in the analyzer (and related packages) from
SCREAMING_CAPS to camelCase.
Also, the error message code generator is enhanced so that it can
generate error codes using either SCREAMING_CAPS or camelCase, based
on the setting of a temporary constant, `_useLowerCamelCaseNames`. The
constant is currently set to `false`; `rename_error_constants.dart`
will change it to `true`.
There are a few references to the old SCREAMING_CAPS names that won't
be able to be automatically addressed by the script. To avoid
breakages, a mechanism has been added to the error message code
generator to preserve those names after the migration, as deprecated
aliases. The names that will be preserved are listed in the
`ErrorClassInfo.deprecatedSnakeCaseNames` field, in
`error_code_info.dart`. These will be cleaned up in future CLs.
Once the rename is complete, the temporary script and constant will be
removed.
Change-Id: I6a6a69640b077c6bc4da92cec97686e4b2c3b906
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444920
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Moritz Sümmermann <mosum@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
'SpecParser.java' has always been using an `ANTLRFileStream`, but this
class has been deprecated at this time. Changing the code to use
`CharStreams.fromFileName(...)`.
Change-Id: I35fce3b381ac2e819794c08faef7f97c4c3bea50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444840
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Tweaking the documentation a tad to enforce the new process of:
1. Add an `experimentalReleaseVersion` when you make the flag and set it to the current latest version at the time of creation.
2. Bump the `experimentalReleaseVersion` when you make a relevant change in the allowlist that would allow those libs/packages to use the feature by default.
The chat thread context: https://chat.google.com/room/AAAA4GpVqbE/r2QigevCdQo/tP7lLb8I728?cls=10
Change-Id: I8ddad40e0ac82b6deaae9a6671bec4d47ea07fba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443636
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Print constants as JSON in runtime/vm/compiler/offsets_extractor.cc
instead of generating C++ declarations.
tools/run_offsets_extractor.dart reads JSON and generates C++
declarations (runtime/vm/compiler/runtime_offsets_extracted.h).
This would allow us to have different output formats in future
(e.g. C++ and Dart).
TEST=dart tools/run_offsets_extractor.dart
Change-Id: Ib8576766ae8cc21583b5a7b27998fd88b733b3a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443140
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The directory location depends on the current OS:
- on Windows:
- `%LOCALAPPDATA%\Dart\<tool>`
- on Mac OS:
- `$HOME/Library/Application Support/Dart/<tool>`
- on Linux:
- `$XDG_STATE_HOME/Dart/<tool>` if `$XDG_STATE_HOME` is defined,
and
- `$HOME/.local/state/Dart/<tool>` otherwise.
The Dart data home can be overridden with the `DART_DATA_HOME`
environment variable.
This CL does not start using the new location yet.
Bug: https://github.com/dart-lang/sdk/issues/60922
Bug: https://github.com/dart-lang/sdk/issues/41560
Bug: https://github.com/flutter/flutter/issues/59430
Change-Id: I55e0ba610f8665ea3c9f053b36c943b097313046
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/440462
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Introduce Dart_LoadLibraryFromBytecode to support loading unit test
libraries from bytecode.
TEST=ci
Change-Id: I7706fdb2acaf906f01f27f671e7193b9755efe0f
Cq-Include-Trybots: luci.dart.try:vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439080
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
https://github.com/dart-lang/sdk/issues/56455
The existing native typed data implementation in dart2js/ddc
and the JS typed data wrappers in dart2wasm do not support
SharedArrayBuffers.
In dart2js/ddc, this is because the native type for ByteBuffer
is simply ArrayBuffer, leading to type failures when using
SharedArrayBuffers. To handle this, this change makes NativeByteBuffer
an abstract parent class to NativeArrayBuffer and NativeSharedArrayBuffer.
This allows ByteBuffer to support both types. There is a preexisting
SharedArrayBuffer type in dart:html that we should avoid breaking, so
we add an interface that NativeSharedArrayBuffer implements and expose
that interface.
In dart2wasm, JSArrayBufferImpl only allows ArrayBuffers as its
extern ref. This change makes that wrapper support SharedArrayBuffers
as well.
In dart:js_interop, the existing toJS conversion on ByteBuffer
now throws if the underlying buffer was actually a SharedArrayBuffer.
This is to support the return type of JSArrayBuffer. This behavior
technically already existed due to type differences in the JS
compilers, but was never possible with dart2wasm.
CoreLibraryReviewExempt: Backend-specific libraries with no real functional changes to public APIs.
Change-Id: I4dac9fb808590bf0c274da815c152cd4637316b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437526
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
- split the Dart CLI tool out of the VM into it's own embedder which
runs in AOT mode. The pure Dart VM executable is called 'dartvm' and
has no Dart CLI functionality in it
- the Dart CLI executable parses the CLI commands and invokes the rest
of the AOT tools in the same process, for the 'run' and 'test'
commands it execs a process which runs 'dartvm' to run
- 'dart hello.dart' execs the 'dartvm' process and runs 'hello.dart'
- the Dart CLI is not generated for ia32 as we are not shipping a
Dart SDK for ia32 anymore (support to execute the 'dartvm' for ia32
architecture is retained)
- the Dart CLI tool is not built in the internal Dart SDK builds
TEST=ci
Some performance improvement numbers
'dart format pkg/dartdev' goes from 1.17 secs to 0.22 secs
'dart doc pkg/dartdev' goes from 100.2 secs to 66.6 secs
'dart fix pkg/dartdev' goes from 19.3 secs to 14.5 secs
Change-Id: I66984a26cb2ab014b34dc1873f1f3d2884e13518
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364202
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Erik Ernst