These files had comments indicating that running
`pkg/analysis_server/tool/spec/generate_files` would regenerate them,
but that was not the case.
Change-Id: I6ceb6352edf6eab5e746276a0a2f33b16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Avoid a race condition between async setenv/unsetenv calls on the VM thread and concurrent getenv/environ reads on the main thread.
In glibc, setenv and getenv are not thread-safe against each other. VmInteropHandler.setEnvironmentVariable previously sent a message to the VM thread to call setenv/unsetenv asynchronously, while the main thread immediately proceeded to access Platform.environment or Platform.localeName (which calls getenv). This could cause a crash (SIGSEGV) in getenv.
This CL makes VmInteropHandler.setEnvironmentVariable synchronous by awaiting a reply from the VM thread before returning.
TEST=pkg/dartdev/test/environment_test.dart
Fixes https://github.com/dart-lang/sdk/issues/63460
Change-Id: Ic8211897ce26ffbdc142fa594cd397189a61f061
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506800
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
Constructor parameters that were only referenced by a `super` parameter
in a primary constructor were being flagged as being unused because the
`super` parameter wasn't being visited. This CL causes all `super`
parameters to be visited.
Change-Id: Iad6eee87b3b74a387d86e783e3bb35300a801c12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507262
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
This addresses a comment on a previous CL by implementing the logic
required to handle the case where the declaring parameter has an old
style function type.
Change-Id: Ie65cc379571800b0d3d5acec82341d315e80ed4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507162
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This updates the resolver to infer all initializers together with the same visitor, avoiding a lot of book keeping needed to pass and compute scope provider info.
Change-Id: If30ee2b3ed4694af9c28af7a2fad3c2252fba0b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507081
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds helpers for creating variables corresponding to the new variable model. This prepares for removing the LegacyVariable and only createing the variables.
This includes a fix for using the new LocalVariable for FunctionDeclaration.
Change-Id: Ib82e12ceb11cf6aa80185bdfeb559461c641dc15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506241
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds internal nodes for FunctionNode, FunctionExpression and FunctionDeclaration which require InternalVariable rather than Variable. This is in preparation for using the new variable model by default.
Change-Id: I3c29954bcaae555c20b37e6a3ba1e70d959f1559
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506941
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed in https://dart-review.googlesource.com/c/sdk/+/497583
[dartpad] Part 1: Protocol and Scaffolding
This sets up folders for `package:dartpad` and `package:dartpad_worker`,
R=athom@google.com, sigurdm@google.com
including:
* `OWNERS` files,
* Protocol definition,
* Exceptions, and,
* Virtual file system utilities.
[dartpad] Part 2: HotReloadCompiler
Adds the hot reload compiler logic to dartpad_worker.
This is models on dartdevc with `--reload-last-accepted-kernel` and
`--reload-delta-kernel` options. I don't think this does an incremental
compilation, instead it does a modular compilation. Meaning, we can have
a huge collection of precompiled DDC modules and the compiler just gets
a DDC outline/summary dill files for these modules. But on the other hand
the actual code that is compiled will be recompiled on every compile()
call.
This is very important for flutter_web.js / flutter_web.dill where the
precompiled DDC modules is around 60 MB in total. The fact that
package:flutter is precompiled into flutter_web.js is critical for
compilation performance for small dartpad-style example apps.
The downside is that unlike incremental compilation with _frontendserver_,
if the user were to install package:http and use it in the app they are
compiling then every `compile()` call will recompile `package:http`.
Where as with _frontendserver_ we'd be able to invalidate specific files,
and only those would be recompiled.
This leaves future work to either:
* (A) Add support for modular compilation to _frontendserver_, such that
we can do incremental compilation without having to first compile all
of `package:flutter`.
* (B) Refactor compilation strategy implemented here, to leverage
modular further. We could for example compile all dependencies from
`PUB_CACHE` into a `pub_cache_outline.dill` inside the dartpad worker.
Then recompilation would only touch the user-code. Granted this is
still less than ideal.
At the moment the lack of incremental compilation is not a blocker,
current dartpad doesn't have incremental compilation, but granted it also
only supported a single file. This dartpad environment will support
multiple files, but adding many files will result in poor performance
until we refactor and figure out how to do incremental compilation.
Hence, why we shouldn't block progress waiting for incremental compilation
to work.
R=nshahan@google.com
[dartpad] Part 3: Pub execution wrapper
Adds the internal wrapper for executing pub commands inside the
worker's virtual file system.
R=sigurdm@google.com
[dartpad] Part 4: Language Server wrapper
Adds the internal wrapper for spawning and communicating with the
Dart LSP inside the DartPad worker.
R=scheglov@google.com
[dartpad] Part 5: DartPad Worker
Implements the main worker entrypoint, RPC message handling. The
`bin/worker.dart` is what will be compiled to WASM and will run as a
_Web Worker_.
R=sigurdm@google.com
[dartpad] Part 6: DartPad Client library
The public-facing `dartpad` library that developers use to embed
the compilation environment in their web applications.
This finishes `package:dartpad`featuring:
* `DartPad.create()`, which creates a _Web Worker_ running the compiled
`pkg/dartpad_worker/bin/worker.dart`, and returns a `DartPad` instance
wrapping RPC calls into the _Web Worker_.
* `Sandbox.createIFrame()` which creates a _sandboxed iframe_ containing
precompiled DDC modules from the SDK assets and `sandbox.js` for
wrapping `ddc_module_loader.js` with an RPC interface. This returns a
`Sandbox` instance wrapping RPC calls into the _sandboxed iframe_,
making it easy to load modules, run library entrypoints (main()),
initiate hot-reload, or launch a flutter app.
This is an initial API design that works. There are minor inconsistencies
and improvements that we should do. But I propose that we do so in
follow-up PRs.
R=sigurdm@google.com
[dartpad] Part 7: Build Targets
Adds a `dartpad` target to the Dart SDK, which produces:
```
out/ReleaseX64/dartpad/
├── dart
│ ├── dart_sdk.js.map
│ ├── sdk.js
│ └── sdk.tar
├── ddc_module_loader.js
├── sandbox.js
├── worker.loader.js
├── worker.mjs
├── worker.support.js
├── worker.wasm
└── worker.wasm.map
```
The `dartpad/` output folder is intended to be used as `assetBaseUrl` in
client libraries provided in `package:dartpad`. And the `dartpad/dart/`
folder is intended to be used as `sdkLocation`. These files are not
intended to be distributed along side the normal Dart SDK, instead we'll
publish them on a CDN and let people use `package:dartpad` to point at
these files. If they want to self-host everything, they can copy from our
CDN or rebuild the files using a local Dart SDK checkout.
These files are also necessary for testing, to ensure that we have proper
integration tests for `pkg/dartpad_worker/`. As we will want to publish
these files on a CDN the actual compiled size in release-mode matters,
thus, we have enabled wasm optimizations steps in this mode.
R=rmacnak@google.com
[dartpad] Part 8: Tests for `package:dartpad` and `pkg/dartpad_worker/`.
We have 3 kinds of tests:
* Unit tests (vm, browser or both),
* Worker tests (vm and browser),
* Integration tests (browser-only).
As the Dart SDK test runner simply executes `*_test.dart` files with
`dart` and doesn't support compiling tests to the browser, launching and
running tests in the browser, we employ `dart test` to run tests. We do
this by having `pkg/dartpad_worker/dart_test.yaml` specify that
`dart test` should look for files names `test_*.dart`, and we then create
`pkg/dartpad_worker/test/ci_test.dart´ to be a single test that simply
runs `dart test` as a subprocess. Thus, the only test file triggered by
Dart SDK test runner is `ci_test.dart`, and if you locally run `dart test`
this will run the individual `test_*.dart` files.
While this hack to use `dart test` isn't ideal it gives everyone a decent
work flow. And saves us from having to invent complex test harness for
`pkg/dartpad_worker/`.
**Worker tests** defined in `test/dart/worker/` and `test/flutter/worker/`
are all imported into `test_dart_worker.dart` and
`test_flutter_worker.dart` to reduce test compilation time. These have a
non-trivial compilation time because the worker is running in the test
process. This allows testing on VM, which can be easier to debug.
**Integration tests** unlike _worker tests_ launch the worker compiled by
the `dartpad` build target in a _Web Worker_. This has less compilation
overhead for the individual tests, but involves more setup, and can be
a bit harder to debug.
Both worker and integration tests employ `test/asset_server/` which serves
assets built by the `dartpad` build target, and serves as a pub-server for
tests. It also serves assets built by `tool/setup_local_flutter.dart`
which creates flutter assets, though this is not intended to run as part
of CI, since we do not have a Flutter checkout available. Thus, for the
time being flutter testing is local only. Maybe, later we'll move this
script to another repository.
R=sigurdm@google.com
Cq-Include-Trybots: luci.dart.try:pkg-linux-release-try,pkg-win-release-try
Change-Id: I3a99939ec5217b9f3a855fc5b9ad9699047d02cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507321
Commit-Queue: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Issue #55173.
Exposes signed min/max on WasmI64 and f64.min/f64.max on WasmF64 in
dart:_wasm, mirroring how WasmF64.sqrt is exposed today. The dart:math
min/max patches in math_patch.dart dispatch to them via runtime
`is`-checks, with @pragma('wasm:prefer-inline') so the inliner folds
the chain to the bare instruction sequence at each call site:
T min<T extends num>(T a, T b) {
if (a is int && b is int) return unsafeCast<T>((a as int).minS(b));
if (a is double && b is double) return unsafeCast<T>((a as double).min(b));
return _minSlow<T>(a, b);
}
Wasm has no native i64 min_s/max_s, so WasmI64.minS/maxS emit the
same local.tee + i64.le_s/ge_s + select sequence. WasmF64.min/max emit
f64.min/f64.max directly.
The NaN- and signed-zero-aware fallback ladder is preserved in
`_minSlow` / `_maxSlow` (out-of-line, no pragma) and called for the
mixed and num cases. tests/lib/math/min_max_test.dart requires type
preservation between equal int and double arguments (e.g.
min(-499, -499.0) is int at line 113; max(499, 499.0) is int at
line 382), which a toDouble().max(toDouble()) fallback would not
satisfy.
Adds pkg/dart2wasm/test/ir_tests/math_min_max.dart covering min/max
for static int/int, double/double, mixed int/double, and num/num.
The .wat locks in f64.min/f64.max for the f64 paths, i64.le_s/i64.ge_s
+ select for the i64 paths, and `call $_minSlow` / `call $_maxSlow`
for mixed and num/num.
Measurements on a probe with four typed call sites (one each for
min<double>, max<double>, min<int>, max<int>, all marked
@pragma('wasm:never-inline')):
* .wasm size: 27,112 → 25,848 bytes (-4.66%). Generic $min and $max
are eliminated by DCE.
* Runtime, 100M iterations per operation on d8, median of 10 runs:
min<double> 543 → 213 ms (2.55x), max<double> 550 → 213 ms (2.58x),
min<int> 552 → 65 ms (8.49x), max<int> 555 → 73 ms (7.61x).
Checksums match between baseline and patched.
tests/lib/math/min_max_test.dart passes.
R=mkustermann@google.com, osa1@google.com
Change-Id: If8cf0a4df976f2d7f2230308905ff68491311c97
Bug: https://github.com/dart-lang/sdk/issues/55173
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503740
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
This change migrates the packages owned by the developer experience
team to use the new constructor declaration syntax, described in
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
This change was performed in an automated fashion, by (a) bumping the
packages' SDK constraints to `3.13.0-0`, (b) enabling the lints
`unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor`, (c) fixing the resulting lint
failures using `dart fix`, and then (d) reformatting the affected
files.
To ease code review, I've reverted unrelated formatting changes.
Since this change requires bumping SDK constaints to `3.13.0-0`, it
was only performed on packages that are *not* published on
pub. (Packages that *are* published on pub should remain on lower
language versions until at least after the stable version of 3.13 is
released, so that we don't block users on the stable channel from
receiving updates to those packages.)
Change-Id: Ibb4daebafd239da58251e838ea6a3f336a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505046
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
I was starting to migrate it to use primary constructors but realized
the formatting was out of date, so I figured I may as well fix that
first so that the migration CL is easier to read.
There are no changes in this CL, I only ran `dart format .`.
Change-Id: I25f772ce0e0a00d83f1f8b561fc8bb9fe9486859
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506741
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Server already supports the opposite, so this just makes it possible to
go both ways.
This doesn't support converting a declaring function typed parameter.
We could add that, but I'm hoping it's rare enough to not be worth doing.
Other than that, I think I've covered all the cases, but please pay
special attention to the test coverage.
Change-Id: I400204ca820d0e0f1cc44075dd54946db79b2115
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506740
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Previously, in the `CheckSorted` presubmit check, if
`verify_sorted_test.dart` returned a nonzero exit code but none of its
output lines contained the string `Unsorted file`, then a presubmit
failure would be generated containing an empty string, resulting in
confusing output like this:
Running presubmit upload checks ...
18.4s to run CheckChangeOnUpload from /home/paulberry/dart1/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
** Presubmit ERRORS: 1 **
Presubmit checks took 21.4s to calculate.
There were presubmit errors.
This might happen, for example, if `verify_sorted_test.dart` contained
a compile-time error or threw an unhandled exception.
With this change, the message is `CheckSorted: could not parse output
of verify_sorted_test.dart`, followed by the full stdout and stderr
from the attempt.
This should make this sort of failure a lot easier to debug.
Note: I've made this same fix before to
`pkg/_fe_analyzer_shared/PRESUBMIT.py` (see
https://dart-review.googlesource.com/c/sdk/+/485601). I didn't realize
at the time that the code was duplicated.
Note: This should make it easier to debug
https://github.com/dart-lang/sdk/issues/63464.
Change-Id: I4892dcff7ad6969ca40564c1fd7e62e36a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506605
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Add helpers that resolve non-test files using the same inline diagnostic
expectation format as resolveTestCodeWithDiagnostics.
resolveFileWithDiagnostics handles a single file, while
resolveFilesWithDiagnostics writes all related files before resolving
any of them.
Add multi-file diagnostic expectation generation so context messages in
one file can be referenced from diagnostics reported in another. Teach
expectation updating how to target values in a files-to-code map using
per-entry intra-invocation ids.
Remove assertErrorsInFile2 and migrate diagnostics tests from
hand-written ExpectedError offsets to inline markers. This keeps the
diagnostic range, code, message, and cross-file context next to the code
under test, and makes expectation updates reusable for library and part
tests.
Initialize strong-mode type assertions from resolveFile so callers that
resolve files other than testFile get the same setup.
Change-Id: Ie492155b046c28a535faf21fa9a2e47797caffb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506180
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It would incorrectly put the primary constructor parameter list before
the type's type parameter list, like:
```dart
// Before:
class C<T> {
C();
}
// After:
class C()<T> {
}
```
This fixes it to follow the type parameter list if there is one.
Change-Id: Ib49c7df7923e9feed11f87579fefc8300c56c4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Work towards https://github.com/dart-lang/sdk/issues/62686
`dart analyze` uses an 'analysis.setAnalysisRoots' "command" to let
the analysis server know that the user requested, for example,
`dart analyze foo` or `dart analyze foo/bar.dart`. This was not conveyed
to analyzer plugins, so analyzer plugins will always analyze the entire
context collection.
(For some reason, only files in the "analysis roots" were reported in
stdout; maybe DAS or dartdev does its own filtering on diagnostics.)
This change forwards the `setAnalysisRoots` request to DAS plugins using
a new protocol message that mirrors the one for the server.
We should not change the behavior of `analysis.setContextRoots` for
legacy plugins, so we keep sending that request as per usual. Then
we send `analysis.setAnalysisRoots` at the same time.
If we receive an `analysis.setAnalysisRoots` message, dispose and
delete references to the existing context collection, and instantiate
a new one, with the specified `included` and `excluded` paths.
Change-Id: I53627da1c30351a22b5e5410a557bf486620a7aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505041
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Pass in the entry-points and OS to the link hook when the record_use
file is provided. So that different target OSes and different entry-
points are cached separately.
Also, commit skill to rev `native_rev` in DEPS. (The new agent
IDE ignores gemini.md that contained it and prefers using skills.)
Change-Id: Ic77e3ccd5915736081c01f8b75901f626f688f19
Cq-Include-Trybots: luci.dart.try:dart2wasm-asserts-linux-chrome-try,dart2wasm-asserts-minified-linux-d8-try,dart2wasm-linux-chrome-try,dart2wasm-linux-d8-try,dart2wasm-linux-firefox-try,dart2wasm-linux-jscm-chrome-try,dart2wasm-linux-optimized-jsc-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,dart2js-canary-linux-try,dart2js-hostasserts-linux-d8-try,dart2js-linux-chrome-try,dart2js-linux-firefox-try,dart2js-mac-chrome-try,dart2js-mac-safari-try,dart2js-minified-csp-linux-chrome-try,dart2js-minified-linux-d8-try,dart2js-unit-linux-x64-release-try,dart2js-win-chrome-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506580
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
This CL introduces support for anonymous block methods (that is,
`e.{ print(this); }` as opposed to `e.=> print(this);`). It introduces
the notion of a `ReturnContext` which is used to change the semantics
of a return statement when it returns from an anonymous method (where
it works like a `break` that terminates the execution of the block
which is the body of the enclosing anonymous method), but keeps the
semantics of return statements returning from a function (including
function literals) still have the same semantics as today.
Change-Id: I404459361fbb7c2e495e46d1bd29924063f3aac4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503800
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Paul Berry