change BorrowKind::Unique to be a mutating PlaceContext

[lcnr]

fixes #112056

I believe that BorrowKind::Unique is a footgun in general, so I added a FIXME and opened #112072. This is a bit too involved for this PR though.

[rustbot]

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

[oli-obk]

@bors r+

[bors]

📌 Commit 25f8f4c has been approved by oli-obk

It is now in the queue for this repository.

[wesleywiser]

@bors p=10

Beta nominated backport for P-critical issue.

[bors]

⌛ Testing commit 25f8f4c with merge e6e4f7e...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing e6e4f7e to master...

[cormac-ainc]

Is there any chance of this landing in stable 1.70? It seems to me that it's an easy enough thing to hit with very innocent-looking code (like this example which exploits lifetime elision to really bury the unsoundness) that there could be serious harm done by leaving it in stable for another 6 weeks. There's also the option of a 1.70.1 if it is too late now.

Our team downgraded to 1.68.2 this week, as we're wrangling lifetimes, we already hit the issue by accident, and it's just too big a hole in borrowck.

[rust-timer]

Finished benchmarking commit (e6e4f7e): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 643.715s -> 643.102s (-0.10%)

[klensy]

Is there any chance of this landing in stable 1.70? It seems to me that it's an easy enough thing to hit with very innocent-looking code (like this example which exploits lifetime elision to really bury the unsoundness) that there could be serious harm done by leaving it in stable for another 6 weeks. There's also the option of a 1.70.1 if it is too late now.

Our team downgraded to 1.68.2 this week, as we're wrangling lifetimes, we already hit the issue by accident, and it's just too big a hole in borrowck.

This PR labeled as stable-nominated, so i guess it will be backported to stable.

[pnkfelix]

Unilaterally accepting for stable- and beta-backports, based on consensus decision between @wesleywiser and myself as T-compiler co-leads.

@rustbot label: +stable-accepted +beta-accepted

[cormac-ainc]

I want to thank everyone who worked hard on this, under pressure and at a difficult time. I understand it took an unusual effort to get it done, and I really appreciate it. There's a lot to be proud of there.

[cormac-ainc]

(One last thing to note is that because this was so extraordinarily last-minute, the fix didn't make it into beta. I suppose it will need to be backported before the next stable promotion, otherwise it will sneak back into stable, right?)

[pnkfelix]

(One last thing to note is that because this was so extraordinarily last-minute, the fix didn't make it into beta. I suppose it will need to be backported before the next stable promotion, otherwise it will sneak back into stable, right?)

I'm hoping PR #112246 means its in beta now?

[Mark-Simulacrum]

Yeah, this should be in beta now.