regression: temporary value dropped while borrowed

[Mark-Simulacrum]

https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/reg/munge-0.3.0/log.txt

[INFO] [stdout] error[E0716]: temporary value dropped while borrowed
[INFO] [stdout]    --> src/lib.rs:194:18
[INFO] [stdout]     |
[INFO] [stdout] 194 |         a = &mut MaybeUninit::uninit();
[INFO] [stdout]     |                  ^^^^^^^^^^^^^^^^^^^^^- temporary value is freed at the end of this statement
[INFO] [stdout]     |                  |
[INFO] [stdout]     |                  creates a temporary value which is freed while still in use
[INFO] [stdout] 195 |         b = &mut MaybeUninit::uninit();
[INFO] [stdout] 196 |         let _ = a;
[INFO] [stdout]     |                 - borrow later used here
[INFO] [stdout]     |
[INFO] [stdout] help: consider using a `let` binding to create a longer lived value
[INFO] [stdout]     |
[INFO] [stdout] 194 ~         let binding = MaybeUninit::uninit();
[INFO] [stdout] 195 ~         a = &mut binding;
[INFO] [stdout]     |

[asquared31415]

edit: whoops there was an FCP for this in #104844 (which is the regressing PR)

searched nightlies: from nightly-2023-04-17 to nightly-2023-06-06
regressed nightly: nightly-2023-04-23
searched commit range: fec9adc...b628260
regressed commit: 21fab43

[hameerabbasi]

edit: whoops there was an FCP for this in #104844 (which is the regressing PR)

This particular failure wasn't mentioned in that PR, however. Perhaps it was missed.

[Noratrieb]

cc @cjgillot, crater on the PR found no regressions but we got one here. @djkoloski this is your crate^^

[lqd]

Interesting, munge-0.3.0 didn't appear as a regression then because it was categorized "broken: missing some deps" by both the before and after toolchains, so #104844 didn't run on it at the time.

[djkoloski]

I've fixed the offending tests in tree. It looks like this regression only affected the specific test code, not any functional part of the crate.

[apiraino]

WG-prioritization removing priority (Zulip discussion).

tbh I'm unsure on the best course of action here: maybe close the issue rather than leave in a undefined state? IIUC I see no clear actionable for us.

@rustbot label -I-prioritize

[apiraino]

I think the previous evaluation still stands (again: unless I'm missing some context). @Mark-Simulacrum does it make sense to remove the prioritization? And/or closing the issue?

[Enselic]

maybe close the issue rather than leave in a undefined state? IIUC I see no clear actionable for us.

No objections for over a year. Let's close.