don't leak internal temporaries from dbg!, even on false unwind paths#155915
don't leak internal temporaries from dbg!, even on false unwind paths#155915dianne wants to merge 2 commits intorust-lang:mainfrom
dbg!, even on false unwind paths#155915Conversation
|
The Clippy subtree was changed cc @rust-lang/clippy |
d0ae98f to
b896b20
Compare
|
t-compiler will defer backport decision to t-libs since this is almost entirely in their purview |
|
Maybe it's worth a crater run compared to stable? |
|
@bors try |
This comment has been minimized.
This comment has been minimized.
don't leak internal temporaries from `dbg!`, even on false unwind paths
|
I just meant stable vs. this nightly -- which will include other changes, but that's true if we beta-backport too. I think we can just do this: @craterbot check start=1.95.0 |
This comment was marked as resolved.
This comment was marked as resolved.
|
@craterbot check start=1.95.0 end=try#012cd62c9add58ab3910e44c137d87db3ab70f61 |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
Bumping priority since this is release-relevant for 1.96-beta. @craterbot name=pr-155915 p=1 |
|
📝 Configuration of the ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Hopefully fixes #155902 for real this time! See #155902 (comment) and the following comments for why I think
matching on a tuple ofdbg!'s arguments seems not to be a viable implementation strategy. Instead, this usessuper letto get better control over scoping, which unfortunately makes for pretty awkward code with the current version ofsuper let.One alternative to this would be reverting all the recent changes to
dbg!for now and re-landing them oncesuper let's replacement is usable. That will probably be the go-to answer for these tricky scoping problems.Another alternative would be to change Rust's static semantics to (hopefully) make the
match-baseddbg!not a problem.I also noticed
std::macros::dbg_internal!seems to be stable in beta (playground), so I've taken the liberty of de-stabilizing it. I can pull that out into a separate PR later if that'd be better, but I figure if we revert the recent changes todbg!, we'd also be reverting the addition ofdbg_internal!, so for now that's here.This may also need clippy and compiler review, but let's start with r? libs