bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Auto merge of #103293 - est31:untwist_and_drop_order, r=nagisa

Browse source 
Remove drop order twist of && and || and make them associative

Previously a short circuiting binop chain (chain of && or ||s) would drop the temporaries created by the first element after all the other elements, and otherwise follow evaluation order. So `f(1).g() && f(2).g() && f(3).g() && f(4).g()` would drop the temporaries in the order `2,3,4,1`. This made `&&` and `||` non-associative regarding drop order. In other words, adding ()'s to the expression would change drop order: `f(1).g() && (f(2).g() && f(3).g()) && f(4).g()` for example would drop in the order `3,2,4,1`.

As, except for the bool result, there is no data returned by the sub-expressions of the short circuiting binops, we can safely discard of any temporaries created by the sub-expr. Previously, code was already putting the rhs's into terminating scopes, but missed it for the lhs's.

This commit addresses this "twist". We now also put the lhs into a terminating scope. The drop order of the above expressions becomes `1,2,3,4`.

There might be code relying on the current order, and therefore I'd recommend doing a crater run to gauge the impact. I'd argue that such code is already quite wonky as it is one `foo() &&` addition away from breaking. ~~For the impact, I don't expect any *build* failures, as the compiler gets strictly more tolerant: shortening the lifetime of temporaries only expands the list of programs the compiler accepts as valid. There might be *runtime* failures caused by this change however.~~ Edit: both build and runtime failures are possible, e.g. see the example provided by dtolnay [below](https://github.com/rust-lang/rust/pull/103293#issuecomment-1285341113). Edit2: the crater run has finished and [results](https://github.com/rust-lang/rust/pull/103293#issuecomment-1292275203) are that there is only one build failure which is easy to fix with a +/- 1 line diff.

I've included a testcase that now compiles thanks to this patch.

The breakage is also limited to drop order relative to conditionals in the && chain: that is, in code like this:

```Rust
let hello = foo().hi() && bar().world();
println!("hi");
```

we already drop the temporaries of `foo().hi()` before we reach "hi".

I'd ideally have this PR merged before let chains are stabilized. If this PR is taking too long, I'd love to have a more restricted version of this change limited to `&&`'s in let chains: the `&&`'s of such chains are quite special anyways as they accept `let` bindings, in there the `&&` is therefore more a part of the "if let chain" construct than a construct of its own.

Fixes #103107

Status: waiting on [this accepted FCP](https://github.com/rust-lang/rust/pull/103293#issuecomment-1293411354) finishing.
This commit is contained in:
bors 2022-12-04 14:03:12 +00:00
commit 19c250aa12
3 changed files with 165 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

47
compiler/rustc_hir_analysis/src/check/region.rs
View file

@ -241,17 +241,46 @@ fn resolve_expr<'tcx>(visitor: &mut RegionResolutionVisitor<'tcx>, expr: &'tcx h
// scopes, meaning that temporaries cannot outlive them.
// This ensures fixed size stacks.
hir::ExprKind::Binary(
source_map::Spanned { node: hir::BinOpKind::And, .. },
_,
ref r,
)
| hir::ExprKind::Binary(
source_map::Spanned { node: hir::BinOpKind::Or, .. },
_,
source_map::Spanned { node: hir::BinOpKind::And | hir::BinOpKind::Or, .. },
ref l,
ref r,
) => {
// For shortcircuiting operators, mark the RHS as a terminating
// scope since it only executes conditionally.
// expr is a short circuiting operator (|| or &&). As its
// functionality can't be overridden by traits, it always
// processes bool sub-expressions. bools are Copy and thus we
// can drop any temporaries in evaluation (read) order
// (with the exception of potentially failing let expressions).
// We achieve this by enclosing the operands in a terminating
// scope, both the LHS and the RHS.
// We optimize this a little in the presence of chains.
// Chains like a && b && c get lowered to AND(AND(a, b), c).
// In here, b and c are RHS, while a is the only LHS operand in
// that chain. This holds true for longer chains as well: the
// leading operand is always the only LHS operand that is not a
// binop itself. Putting a binop like AND(a, b) into a
// terminating scope is not useful, thus we only put the LHS
// into a terminating scope if it is not a binop.
let terminate_lhs = match l.kind {
// let expressions can create temporaries that live on
hir::ExprKind::Let(_) => false,
// binops already drop their temporaries, so there is no
// need to put them into a terminating scope.
// This is purely an optimization to reduce the number of
// terminating scopes.
hir::ExprKind::Binary(
source_map::Spanned {
node: hir::BinOpKind::And | hir::BinOpKind::Or, ..
},
..,
) => false,
// otherwise: mark it as terminating
_ => true,
};
if terminate_lhs {
terminating(l.hir_id.local_id);
}
// `Let` expressions (in a let-chain) shouldn't be terminating, as their temporaries
// should live beyond the immediate expression