| commit | 8546b2e4e6f055a900cca1bb9632bd1ac783fea1 | [log] [tgz] |
|---|---|---|
| author | Sam Rawlins <srawlins@google.com> | Thu Aug 07 12:29:10 2025 -0700 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Aug 07 12:29:10 2025 -0700 |
| tree | 51ad2e354145833cc79e90bd5411cbd770bdd36f | |
| parent | c3ddf2ebdfe5da44f7b7a729388b9cbdd61028cc [diff] |
analyzer_testing: Move Spelunker into this package The Spelunker class is only used by analyzer_testing's PubPackageResolutionTest class, and by a utility script. So I believe the best place for this class is in analyzer_testing, for two reasons: * Would we also move the utility script (`pkg/linter/tool/spelunk.dart`)? This is a script that lets you see a visual tree of the syntax nodes of a Dart script. It has been helpful to people writing lint rules, as it helps you understand how you need to walk up or down the tree to check conditions. Therefore, it will be at least as helpful to people writing analysis rules in analyzer plugins (the primary consumers of PubPackageResolutionTest). It doesn't need to live in `bin` (though that's one possibility). It can live in `analyzer_testing/tool`. * Then if the utility script lives in analyzer_testing, and PubPackageResolutionTest lives in analyzer_testing, and these are the sole consumers of Spelunker, it makes sense to move it into analyzer_testing. It does not need to be public API; just live in the source code. Change-Id: Id607091b35ab83c96b8cd73f0ece63923c934fb4 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444240 Commit-Queue: Samuel Rawlins <srawlins@google.com> Reviewed-by: Paul Berry <paulberry@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.