| commit | 1a8cabb0de3701c08403cae811b25225050504d3 | [log] [tgz] |
|---|---|---|
| author | Danny Tuppeny <danny@tuppeny.com> | Mon Jun 16 12:36:35 2025 -0700 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Jun 16 12:36:35 2025 -0700 |
| tree | ece3e0cc5c5187fdeb1ecc94cf7b6419211cdba0 | |
| parent | 1435ab6111062f6c4cf35f737641ea1cc580637d [diff] |
[analysis_server] Allow 'TEST_SERVER_SNAPSHOT' to provide a full server snapshot path The TEST_SERVER_SNAPSHOT env variable could previously be set to the string "false" to indicate not running the tests using the server snapshot (in which case, we'll instead compile the snapshot to a temp location and then use that). This worked well for running the tests via `test_all.dart` where all tests run in a single isolate and share a single compilation. However it doesn't work well through `dart test` (which the VS Code test runner will use so we can get the results in JSON and populate the test tree) because each test runs in its own isolate and therefore still triggered compilation for every test. This expands the `TEST_SERVER_SNAPSHOT` env variable to also support passing another string, which is a path. If provided, this path is used as the snapshot instead (with no compilation). With a small amount of configuration for Dart-Code (which will be documented and/or committed into the `.vscode/` folder here), this will allow Dart-Code to compile the snapshot when running integration tests, and then trigger `dart test` with the env var set, meaning all integration tests across all isolates will share the same compilation. The goal is to be able to make changes to the server and seamlessly run the integration tests from the editor without having to remember to run any external compilation (and for the integration tests to not take 17 minutes). Change-Id: Ia2ef13da8d9a4debe9fa2c8016ef021f6abed8b5 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434800 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Reviewed-by: Samuel Rawlins <srawlins@google.com> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Dart is:
Approachable: Develop with a strongly typed programming language that is consistent, concise, and offers modern language features like null safety and patterns.
Portable: Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend. Compile to JavaScript or WebAssembly for the web.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app. Diagnose app issues using DevTools.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents in our repo at docs.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.
Future plans for Dart are included in the combined Dart and Flutter roadmap on the Flutter wiki.