https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=automation/bors/try 2023-01-11T09:32:08+00:00 2023-01-11T09:32:08+00:00 Albert Larsan 74931857+albertlarsan68@users.noreply.github.com 2023-01-05T08:13:28+00:00 urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfe 2023-01-04T19:44:30+00:00 Caio c410.f3r@gmail.com 2023-01-04T19:44:30+00:00 urn:sha1:7ffcedf6659d30c4a076d89b2586b385ad2f2d16 2022-12-11T22:43:42+00:00 Caio c410.f3r@gmail.com 2022-12-11T22:43:42+00:00 urn:sha1:645fac3e1d788b0d9a2fe150f185be496a0bf885 2022-12-04T03:09:40+00:00 est31 MTest31@outlook.com 2022-12-03T23:21:19+00:00 urn:sha1:a59a2d3f6a80001b0610f03cfc7a6452b63f8935 This avoids creation of a terminating scope in chains that contain both && and ||, because also there we know that a terminating scope is not neccessary: all the chain members are already in such terminating scopes. Also add a mixed && / || test. 2022-12-03T22:32:08+00:00 est31 MTest31@outlook.com 2022-10-20T07:50:32+00:00 urn:sha1:8cf521d80e9057211629e92aff059dc9770c20bd Previously a short circuiting && chain would drop the first element after all the other elements, and otherwise follow evaluation order, so code like: 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, so 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". In the expression, we now also put the lhs into a terminating scope. The drop order for the above expressions is 1,2,3,4 now. 2022-11-23T20:17:47+00:00 Esteban Küber esteban@kuber.com.ar 2022-11-03T04:22:24+00:00 urn:sha1:9e72e35ceb2af024e8ca6a74442269f7ec739173 2022-10-20T14:08:44+00:00 Caio c410.f3r@gmail.com 2022-10-20T14:08:44+00:00 urn:sha1:c74165d443378407baeee7fd8b62a9f46068b938 2022-10-16T22:13:01+00:00 Nathan Whitaker nathan.whitaker01@gmail.com 2022-10-14T03:13:52+00:00 urn:sha1:3041bc9e71355eea71a5070b7939439fd3cf7e01 2022-10-15T10:15:32+00:00 Dylan DPC 99973273+Dylan-DPC@users.noreply.github.com 2022-10-15T10:15:32+00:00 urn:sha1:b79ad57ad7dae81e27fb37b8c703dc4e4acdb7a7 Drop temporaries created in a condition, even if it's a let chain Fixes #100513. During the lowering from AST to HIR we wrap expressions acting as conditions in a `DropTemps` expression so that any temporaries created in the condition are dropped after the condition is executed. Effectively this means we transform ```rust if Some(1).is_some() { .. } ``` into (roughly) ```rust if { let _t = Some(1).is_some(); _t } { .. } ``` so that if we create any temporaries, they're lifted into the new scope surrounding the condition, so for example something along the lines of ```rust if { let temp = Some(1); let _t = temp.is_some(); _t }. ``` Before this PR, if the condition contained any let expressions we would not introduce that new scope, instead leaving the condition alone. This meant that in a let-chain like ```rust if get_drop("first").is_some() && let None = get_drop("last") { println!("second"); } else { .. } ``` the temporary created for `get_drop("first")` would be lifted into the _surrounding block_, which caused it to be dropped after the execution of the entire `if` expression. After this PR, we wrap everything but the `let` expression in terminating scopes. The upside to this solution is that it's minimally invasive, but the downside is that in the worst case, an expression with `let` exprs interspersed like ```rust if get_drop("first").is_some() && let Some(_a) = get_drop("fifth") && get_drop("second").is_some() && let Some(_b) = get_drop("fourth") { .. } ``` gets _multiple_ new scopes, roughly ```rust if { let _t = get_drop("first").is_some(); _t } && let Some(_a) = get_drop("fifth") && { let _t = get_drop("second").is_some(); _t } && let Some(_b) = get_drop("fourth") { .. } ``` so instead of all of the temporaries being dropped at the end of the entire condition, they will be dropped right after they're evaluated (before the subsequent `let` expr). So while I'd say the drop behavior around let-chains is _less_ surprising after this PR, it still might not exactly match what people might expect. For tests, I've just extended the drop order tests added in #100526. I'm not sure if that's the best way to go about it, though, so suggestions are welcome. 2022-10-14T01:29:25+00:00 Nathan Whitaker nathan.whitaker01@gmail.com 2022-10-14T01:29:25+00:00 urn:sha1:4e1c09dcd64507c03ded02844c1e5022031b9e38