Repository navigation
"a temporary value which is freed while still in use" in nightly but not on stable #105891
Copy link
Copy link
Closed
Closed
Copy link
Labels
C-bugCategory: This is a bug.Category: This is a bug.P-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Milestone
Description
Code
I tried this code:
// Do: cargo add obfstr
fn main() {
let product = "macos";
let is_not = |s| !product.eq_ignore_ascii_case(s);
let _res = is_not(obfstr::obfstr!("windows")) && is_not(obfstr::obfstr!("macos"));
}I expected to see this happen: the code compiles without problems on stable and nightly
Instead, this happened: compilation failed but only on nightly
RUSTFLAGS="-Z macro-backtrace" cg +nightly build -q
error[E0716]: temporary value dropped while borrowed
--> /Users/alexis/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/obfstr-0.4.1/src/bytes.rs:93:16
|
54 | macro_rules! obfstr {
| ------------------- in this expansion of `obfstr::obfstr!` (#1)
...
66 | $crate::unsafe_as_str($crate::obfbytes!($s.as_bytes()))
| -------------------------------- in this macro invocation (#2)
...
72 | macro_rules! obfbytes {
| --------------------- in this expansion of `$crate::obfbytes!` (#2)
...
86 | &$crate::__obfbytes!($s)
| ----------------------- in this macro invocation (#3)
...
92 | macro_rules! __obfbytes {
| ----------------------- in this expansion of `$crate::__obfbytes!` (#3)
93 | ($s:expr) => {{
| ___________________^
94 | | const _OBFBYTES_STRING: &[u8] = $s;
95 | | const _OBFBYTES_LEN: usize = _OBFBYTES_STRING.len();
96 | | const _OBFBYTES_KEYSTREAM: [u8; _OBFBYTES_LEN] = $crate::bytes::keystream::<_OBFBYTES_LEN>($crate::__entropy!("key", stringify!($...
... |
103 | | &_OBFBYTES_KEYSTREAM)
104 | | }};
| |_____^ creates a temporary value which is freed while still in use
|
::: src/main.rs:5:49
|
5 | let _res = is_not(obfstr::obfstr!("windows")) && is_not(obfstr::obfstr!("macos"));
| --------------------------- ------ borrow later used here
| | |
| | temporary value is freed at the end of this statement
| in this macro invocation (#1)
|
= note: consider using a `let` binding to create a longer lived value
For more information about this error, try `rustc --explain E0716`.
error: could not compile `pg2` due to previous error
Version it worked on
It most recently worked on: Rust 1.66
Version with regression
rustc --version --verbose:
rustc 1.68.0-nightly (d0dc9efff 2022-12-18)
binary: rustc
commit-hash: d0dc9efff14ac0a1eeceffd1e605e37eeb8362a0
commit-date: 2022-12-18
host: aarch64-apple-darwin
release: 1.68.0-nightly
LLVM version: 15.0.6
Backtrace
Backtrace
<backtrace>
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.P-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Activity
poliorcetics commentedon Dec 19, 2022
This also fails in beta, (Rust 1.67 beta)
@rustbot label +regression-from-stable-to-beta
zachs18 commentedon Dec 19, 2022
albertlarsan68 commentedon Dec 19, 2022
searched nightlies: from nightly-2022-10-29 to nightly-2022-12-08 (around where beta branched)
regressed nightly: nightly-2022-12-05
searched commit range: 2341517...53e4b9d
regressed commit: 19c250a (#103293, cc @est31 and @nagisa)
bisected with cargo-bisect-rustc v0.6.5
Host triple: x86_64-pc-windows-msvc
Reproduce with:
@rustbot label -regression-from-stable-to-nightly
est31 commentedon Dec 19, 2022
This also fails on stable if you have a three-chain. E.g.:
gives:
I need to investigate more on what obfstr is doing, but it's likely that this is an expected breakage. With #103293, it was known that it is going to cause some breakage. crater runs showed only one regression at build time.
A workaround is easy, you can add
&str:That way, your code will also work with three-chains.
jruderman commentedon Dec 19, 2022
I guess adding
&strchanges the closure to borrow instead of move? Should the compiler suggest adding&str?est31 commentedon Dec 19, 2022
Hmm this is basically the same regression as the one that broke spaad_internal.
Reducing the example from above to not need
obfstr:The best would be to fix the underlying closure lifetime (or type?) inference issue that got surfaced (not caused) by my PR in these instances. If that doesn't work, a suggestion would definitely improve things I think. I don't really know how those parts of the compiler work tho.
apiraino commentedon Dec 21, 2022
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-medium
poliorcetics commentedon Aug 7, 2026
Lint is now (using est31's reduced example above)
which I feel is a lot clearer and fixes the issue