mirror of
https://github.com/dart-lang/sdk
synced 2024-09-05 00:13:50 +00:00
907e705307
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> |
||
---|---|---|
.. | ||
co19 | ||
co19_2 | ||
corelib | ||
corelib_2 | ||
dartdevc | ||
dartdevc_2 | ||
ffi | ||
ffi_2 | ||
language | ||
language_2 | ||
lib | ||
lib_2 | ||
modular | ||
standalone | ||
standalone_2 | ||
web | ||
web_2 | ||
legacy_status_dart2js.csv | ||
OWNERS | ||
README.md |
This directory contains tests of the language and core library implementations. For more information, see https://github.com/dart-lang/sdk/wiki/Testing.