[vm/compiler] Prune SSA during construction using liveness Only insert Phi at JoinEntry and Parameter at CatchBlockEntry if corresponding variable is alive into the block. This keeps insertion consistent with environment pruning logic employed by RenameRecursive: which prunes dead variables out environments when entering the block based on contents of the live_in set. Previously we would insert Parameter instructions for dead variables which lead to an incorrect (unsound) set of catch entry moves generated by the backend due to an inconsistency between Parameter insertion and environment pruning logic and the fact that catch entry moves generator would simply ignore all moves if the source of the move was an optimized_out (aka constant_dead) marker. The following situation was possible: if the variable was assigned inside the try and partially alive inside of it (e.g. we had blocks where it was alive and blocks where it was not) then we would end up inserting Parameter for it, but some of the exceptional edges (corresponding to blocks where the variable was dead) would carry optimized_out value into that Parameter. However `CatchEntryMoveFor` would not record these moves leading to uninitialized garbage arriving on those exceptional edges instead. Note that Phis were not susceptible to the same issue as Parameters because regalloc / backend would not treat optimized_out value specially. This change converts silent treatment of optimized_out in the catch entry moves generation into a release assert instead. Reviewing other uses of constant_dead in the compiler revealed a bug in canonicalization rule for `o.runtimeType` which did not take exceptional edges into account. We add a regression test for that and fix that issue as well. Fixes https://github.com/dart-lang/sdk/issues/59822 TEST=vm/dart/regress_59822,vm/dart/regress_runtime_type_in_trycatch Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-linux-product-x64-try,vm-aot-linux-release-arm64-try,vm-aot-linux-release-simarm_x64-try,vm-aot-linux-release-x64-try Change-Id: I8dc397cb98d84048a1791b9dd6baa7586a2688c6 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403583 Reviewed-by: Alexander Aprelev <aam@google.com> Commit-Queue: Slava Egorov <vegorov@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.