de-RFC: Remove unsized_locals

[Noratrieb]

Original RFC

New RFC

[workingjubilee]

Typos.

[kennytm]

I hope that this won't affect feasibility of #2884 (basically unsized_return).

[Jules-Bertholet]

I think this exaggerates the danger. For example, maybe you are writing code for an embedded system with a low amount of memory. You want to use trait objects to save on code size, but also don’t want to pull in an allocator. In this case, dynamic alloca could be very helpful for reducing memory usage.

And, as others have mentioned, there are many other safe and easy ways of overflowing the stack in Rust. We don’t generally call e.g. recursion an “advanced optimization feature” that’s so scary it’s “similar to unsafe”.

[Jules-Bertholet]

I agree that we still need to figure out the best way to expose the feature, but I think that the best way to do that is to implement it properly on nightly and enable experimentation. Right now, we have vague concerns about footguns and blowing the stack, but without concrete user feedback, it’s impossible to determine how severe the issue is or how the problem could be mitigated.

[Jules-Bertholet]

E.g. maybe lints could address the danger. Or maybe all unsized locals should be annotated in some way (e.g. let #[unsized] foo = …). We can’t try those things out unless we have a proper implementation.

[workingjubilee]

Then go implement it if you think it's such a good idea.

[Jules-Bertholet]

My point is, it’s hard to experiment with the frontend/syntax parts of the feature, if the codegen/backend is missing/broken.

[Noratrieb]

No significant experimentation has happened for the past eight years. I wouldn't hold my beer.

[workingjubilee]

Right, it's actually the middle-end that we're missing, I think? Because MIR is kinda its own beast?

[Jules-Bertholet]

No significant experimentation has happened for the past eight years.

Yes, because the middle/back-end implementation is broken, scaring nightly users away. If the compiler team would rather strip out that broken implementation than continue to let it rot, I have no objection. But rust-lang/compiler-team#630 is enough for that. IIUC this de-RFC would require anyone motivated to implement the feature properly, to go through the full RFC process first. I think that’s going too far. My preference would be to “downgrade” #1909 to an eRFC, instead of unaccepting it completely.

[workingjubilee]

Changing it to an "experimental" RFC will not change that right now it is a gravestone of a feature that no one wants to proceed on. Yes, probably someone should go through the RFC process again, because right now there's not even a draft of a proposal for how it may be implemented in rustc's semantic layers.

[Jules-Bertholet]

it is a gravestone of a feature that no one wants to proceed on

I wouldn’t say that. For example, someone recently put in the effort to fix the longstanding issue with unsized locals being misaligned. Clearly there are some people still interested in this.

[workingjubilee]

I believe that what @tmiasko was touching on there involved fixes to parts of the code that were shared between unsized_locals and unsized_fn_params, because code that accepts unsized_fn_params sometimes, due to the way codegen works, creates unsized temporaries, i.e. locals. That then requires handling that for unsized_fn_params. Our current rude hack that addresses this involves blocking inlining for unsized_fn_params, since that's one of the conditions to reach that.

Also see:

• Inlining introduces unsized temporaries rust#111355
• unsized_fn_params allows some unsized locals rust#111175

[burdges]

It'd be cool if unsized_return could return into some future unsized_local, which sounds impossible with the alloca crate. An unsized_local that's less natural feeling sounds reasonable though. Anyways, the alloca crate has only three dependents, so maybe nobody cares enough.

[Jules-Bertholet]

I would like to understand the “MIR semantics” issues in more detail. What exactly would the compiler team need to see before it would become possible to move forward? rust-lang/compiler-team#630 says:

The [MIR semantics] that const eval used to implement - before support was removed - were known to be awkward and surprising.

But doesn’t link to any of that discussion. It’s hard for people to step up and address the problems, without a clear summary of what they are.

[workingjubilee]

Even then, a detailed summary of the problems would also have to be updated for changes in MIR semantics since then, no? Which may be potentially quite a bit.

[Jules-Bertholet]

I found rust-lang/rust#48055 (comment) which seems to be what I was looking for, or at least a start.

[Noratrieb]

I added a link to the comment in 5bc1184

[Jules-Bertholet]

I started a discussion about fixing the MIR on Zulip: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/MIR.20semantics.20for.20unsized.20locals

[scottmcm]

I think de-RFCing the local variables part of this makes sense.

The original FCP was

I am not recommending an experimental RFC because I don't think we'll be making vast changes to the technical plan laid out here

But it seems like what we'd ended up hitting is that we really do need a fairly drastic re-work of how this works internally (since we don't have a MIR semantic for it) and plausibly also a re-work of how the syntax should behave (because we don't necessarily want this to silently happen).

Notably, like how the type ascription de-RFC wasn't a "we don't want type ascription at all" statement, I don't see this de-RFC as a statement that "we don't want allocas ever". If a feature with similar motivation comes back that's fine; this is just recognizing that the current state here doesn't seem to be stabilization-track and probably getting there deserves a new RFC.

My understanding is that this de-RFC is intentionally not touching unsized_parameters, which sounds appropriate to me. [EDIT: the RFC has been updated to say this very directly as well.]

@rfcbot fcp merge

[rfcbot]

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• clarify-what-is-normative (de-RFC: Remove unsized_locals #3829 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[Jules-Bertholet]

Reiterating the point I made here in a now-resolved thread:

Rust has two main kinds of unsized types: slices and trait objects. Putting unsized slices on the stack is analogous to VLAs in C, and is footgunny and useless to about the same degree. However, putting trait objects on the stack—something which has no analogue in C—is much less likely to cause an overflow, and also offers far more utility.

[scottmcm]

I think it probably depends greatly on the trait involved. Trivially dyn AsRef<[u8]> is not materially better than [u8] on the stack, and dyn coroutines of various types can also be much too large to be good on the stack.

Though I do agree that dyn SqlBackend or similar might have much more of a reasonable size expectation that might make putting it on the stack less worrisome.

[Jules-Bertholet]

Trivially dyn AsRef<[u8]> is not materially better than [u8] on the stack

And impl AsRef<[u8]> is also going to be equally bad, but we allow that today. #3829 (comment)

[traviscross]

While I'm OK with de-RFCing this, as probably I do want someone to write a fresh RFC, if we were to actually do this¹, that made the case for how this should be done in the context of Rust as it is today, I don't want to commit to the following as a normative position:

Which is where we get to the major argument of this RFC: The unsized_locals feature integrates far too naturally into Rust. This makes the feature very easy to use, and especially easy to use accidentally.

Maybe that's correct, maybe it's not (as @Jules-Bertholet is arguing above). Probably I'd want to see an RFC arguing the case for what the right approach is (and read through the threads of all the prior RFCs), and I don't want to prejudge that.

In accepting an RFC, we generally aren't necessarily accepting the motivation or other non-normative sections as the position of the team, so perhaps I could check a box anyway. But there's a lot of normative-sounding language in this RFC, e.g.,

As a dangerous feature, dynamic stack allocation must be explicit and obvious - and unsized_locals makes it implicit by design. Therefore, unsized_locals must go.

and it's not clear to me what the intended normative sections are. If this can adjusted a bit so that it's clear that this RFC isn't committing normatively to this, but is rather raising this as one item that a future RFC should clearly speak to, and that the position taken here is the author's only, then I'll happily check a box.

I'd be happy both to do that and for @Jules-Bertholet or others to pursue an experiment to see if dynamic stack allocation can be done correctly in Rust, and to explore the best way to expose that in the language.

Footnotes

1. ...after an acceptable experimental implementation were to be done. ↩

[traviscross]

@rfcbot concern clarify-what-is-normative

As mentioned, I'd like to avoid taking a normative position on how this might be done in the future, but in any event, we should clarify what exactly is normative here and therefore what our proposed FCP represents, so I'll file a concern to that effect.

It'd be OK, I think, if the only normative aspect of this RFC is that, by virtue of this de-RFC, someone needs to write a new RFC in order to eventually stabilize this.

[Jules-Bertholet]

Which is where we get to the major argument of this RFC: The unsized_locals feature integrates far too naturally into Rust. This makes the feature very easy to use, and especially easy to use accidentally.

Maybe that's correct, maybe it's not (as @Jules-Bertholet is arguing above).

To be clear, though I think the RFC’s language on this is too strong, I do agree that there is a real and serious concern here, and it would have to be addressed before stabilization.

It'd be OK, I think, if the only normative aspect of this RFC is that, by virtue of this de-RFC, someone needs to write a new RFC in order to eventually stabilize this.

I fully agree with this, this would address all my objections.

[bjorn3]

Suggested change

	[RFC 1808] then changed to propose the the VLA syntax instead.
	[RFC 1808] then changed to propose the VLA syntax instead.

[bjorn3]

Should we add a reference to this de-RFC to the type ascription de-RFC as posterior art?