![]() Previously, the flow control logic for patterns didn't use the `FlowModel.split` or `FlowModel.unsplit` methods at all. This meant that if a control flow join point occurred in pattern logic, flow analysis would consider the split point to be whatever split point was established by the enclosing expression or statement. In the case of an if-case statement, it would consider the split point to be at the beginning of the scrutinee expression. Split points are used by flow analysis for the sole purpose of ensuring that joins propagate type promotions the same way in dead code as they do in live code (so that users introducing temporary `throw` expressions or `return` statements into their code do not have to deal with nuisance compile errors in the (now dead) code that follows. The consequence of flow analysis considering the split point to be at the beginning of the scrutinee expression is that if the scrutinee expression is proven to always throw, then joins that arise from the pattern or guard may not behave consistently with how they would have behaved otherwise. For example: int getInt(Object o) => ...; void consumeInt(int i) { ... } test(int? i) { if ( // (1) getInt('foo') case // (2) int() // (3) when i == null) { } else { // (4) consumeInt(i); } } In the above code, there is a join point at (4), joining control flows from (a) the situation where the pattern `int()` failed to match, and (b) the situation where `i == null` evaluated to `false` (and hence `i` is promoted to non-nullable `int`). Since the return type of `getInt` is `int`, it's impossible for the pattern `int()` to fail, so at the join point, control flow path (a) is considered unreacable. Therefore the promotion from control flow path (b) is kept, and so the call to `consumeInt` is valid. In order to decide whether to preserve promotions from one of the control flow paths leading up to a join, flow analysis only considers reachability relative to the corresponding split point. Prior to this change, the split point in question occurred at (1), so if the expression `getInt('foo')` had been replaced with `getInt(throw UnimplementedError())`, flow analysis would have considered both control flow paths (a) and (b) to be unreachable relative to the split point, so it would not have preserved the promotion from (b), and there would have been a compile time error in the (now dead) call to `consumeInt`. This change moves the split point from (1) to (2), so that changing `getInt('foo')` to `getInt(throw UnimplementedError())` no longer causes any change in type promotion behavior. The implementation of this change is to add calls to `FlowModel.split` and `FlowModel.unsplit` around all top-level patterns. At first glance this might appear to affect the behavior of all patterns, but actually the only user-visible effect is on patterns in if-case statements, because: - In switch statements and switch expressions, there is already a split point before each case. - In irrefutable patterns, there is no user-visible effect, because irrefutable patterns cannot fail to match, and therefore don't do any control flow joins. This change allows the split points for patterns to be determined by a simple syntactic rule, which will facilitate some refactoring of split points that I am currently working on. Change-Id: I55573ba5c28b2f2e6bba8731f9e3b02613b6beb2 Bug: https://github.com/dart-lang/sdk/issues/53167 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319381 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Commit-Queue: Paul Berry <paulberry@google.com> |
||
---|---|---|
.dart_tool | ||
.github | ||
benchmarks | ||
build | ||
docs | ||
pkg | ||
runtime | ||
samples | ||
sdk | ||
tests | ||
third_party | ||
tools | ||
utils | ||
.clang-format | ||
.gitattributes | ||
.gitconfig | ||
.gitignore | ||
.gn | ||
.mailmap | ||
.style.yapf | ||
.vpython | ||
AUTHORS | ||
BUILD.gn | ||
CHANGELOG.md | ||
codereview.settings | ||
CONTRIBUTING.md | ||
DEPS | ||
LICENSE | ||
OWNERS | ||
PATENT_GRANT | ||
PRESUBMIT.py | ||
README.dart-sdk | ||
README.md | ||
sdk.code-workspace | ||
sdk_args.gni | ||
SECURITY.md | ||
WATCHLISTS |
Dart
A client-optimized language for fast apps on any platform
Dart is:
-
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
-
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
-
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
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).
License & patents
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Using Dart
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).
Building Dart
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 on our wiki.
Contributing to Dart
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.