[Jules-Bertholet]

Fixes #164902.

I've taken the liberty of making this abort instead of unwind. .use clones are supposed to be cheap and side-effect-free, I think not unwinding should be part of that.

@rustbot label F-ergonomic_clones A-panic

[rustbot]

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, mir
• compiler, mir expanded to 77 candidates
• Random selection from 21 candidates

[RalfJung]

I've taken the liberty of making this abort instead of unwind. .use clones are supposed to be cheap and side-effect-free, I think not unwinding should be part of that.

Given that we unwind out of drop because there was strong pushback against silently turning unwinds into aborts, I don't think this is a good idea. It's certainly unprecedented and needs careful t-lang consideration.

[nikomatsakis]

So: I think we ought to just remove .use -- I at least do not intend to pursue it anymore. I am interested instead in the a Share trait and move expressions which I think hit a "sweeter spot" in terms of being "low-level enough for a kernel, usable enough for a GUI".

Part of what has made me lose interest is that I expect fewer and fewer Rust users to be manually authoring Rust code, so my main interest is in syntax that makes the runtime semantics clear and which isn't distracting when reading the code. I find the existing let x2 = x.clone() stuff that agents generate today does not meet the bar, it's still distracting, but something like async { foo(move(x.share())) } might well be good enough.

I had not yet proposed removing .use because I wanted to land the move-expressions first and I wanted to see how it felt after some time. But in general I don't expect to personally champion .use anymore -- maybe someone else on the @rust-lang/lang or @rust-lang/lang-advisors wants to take up the guantlet, that's fine.

That said, I generally would like to abort on unwind here. My preference would be to also abort on unwind from destructors and probably built-in operators like * and +. Part of my thinking here was that the original idea of .use was that it would sometimes be optimized away in user-visible ways and hence it seems like it has extra potential to be surprising if it sometimes panics and sometimes doesn't (though I guess sometimes aborting is perhaps equally surprising, but the hope would be that it would discourage the use of panic).

That said, I agree with @RalfJung that just aborting here is kind of inconsistent, and as I'm writing about this, I realize that e.g. Rc::clone may panic (another thing I don't love). So I guess this all ends up reinforcing my original feeling that I'd rather just remove .use and not think about it anymore.

[Jules-Bertholet]

@nikomatsakis Personally, I still like .use, but as a complement to move expressions—which I also like, and agree we should definitely ship first. If nobody else wants to pick up the feature, would it be OK for me to take responsibility for it? I'm already mucking around in related parts of the codebase, for rust-lang/rfcs#4011 among other things. My objective would be to strip some parts out (use || closures), change others (capture behavior in plain closures), and generally try to make the feature more focused. Eventually, once move expressions have shipped and we have some experience with them, we can re-evaluate the feature.

[Jules-Bertholet]

Closing in favor of #165111