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>
|
||
|---|---|---|
| .. | ||
| _fe_analyzer_shared | ||
| _js_interop_checks | ||
| analysis_server | ||
| analysis_server_client | ||
| analyzer | ||
| analyzer_cli | ||
| analyzer_plugin | ||
| analyzer_utilities | ||
| async_helper | ||
| bisect_dart | ||
| build_integration | ||
| compiler | ||
| dap | ||
| dart2js_info | ||
| dart2js_runtime_metrics | ||
| dart2js_tools | ||
| dart2native | ||
| dart2wasm | ||
| dart_internal | ||
| dartdev | ||
| dds | ||
| dds_service_extensions | ||
| dev_compiler | ||
| expect | ||
| front_end | ||
| frontend_server | ||
| js | ||
| js_ast | ||
| js_runtime | ||
| js_shared | ||
| kernel | ||
| language_versioning_2_7_test | ||
| meta | ||
| mmap | ||
| modular_test | ||
| native_stack_traces | ||
| nnbd_migration | ||
| scrape | ||
| smith | ||
| sourcemap_testing | ||
| status_file | ||
| telemetry | ||
| test_runner | ||
| testing | ||
| vm | ||
| vm_service | ||
| vm_service_protos | ||
| vm_snapshot_analysis | ||
| wasm_builder | ||
| .gitignore | ||
| analysis_options.yaml | ||
| BUILD.gn | ||
| OWNERS | ||
| pkg.dart | ||
| pkg.status | ||
| README.md | ||
Package validation
The packages in pkg/ are automatically validated on the LUCI CI bots. The
validation is largely done by the tools/package_deps package; it can be tested
locally via:
dart tools/package_deps/bin/package_deps.dart
Packages which are published
There are several packages developed in pkg/ which are published to pub.
Validation of these packages is particularly important because the pub tools are
not used for these packages during development; we get our dependency versions
from the DEPS file. Its very easy for the dependencies specified in a package's
pubspec file to get out of date wrt the packages and versions actually used.
In order to better ensure we're publishing correct packages, we validate some properties of the pubspec files on our CI system. These validations include:
- that the dependencies listed in the pubspec are used in the package
- that all the packages used by the source are listed in the pubspec
- that we don't use relative path deps to pkg/ or third_party/ packages
Packages which are not published
For packages in pkg/ which we do not intend to be published, we put the following comment in the pubspec.yaml file:
# This package is not intended for consumption on pub.dev. DO NOT publish.
publish_to: none
These pubspecs are still validated by the package validation tool. The contents are more informational as the pubspecs for these packages are not consumed by the pub tool or ecosystem.
We validate:
- that the dependencies listed in the pubspec are used in the package
- that all the packages used by the source are listed in the pubspec
- that a reference to a pkg/ package is done via a relative path dependency