update aliasing rules section of the reference

[RalfJung]

This makes explicit some de-facto rules that existed at least since Rust 1.0:

• Boxes also have aliasing requirements.
• References must outlive functions they are passed to. (It is not entirely clear that this was intended when the dereferenceable attribute was added, given that the attribute was also added to Box which can definitely be deallocated by functions they are passed to. But when that got fixed in Box is marked as "dereferenceable" for the duration of the call rust#66600, nobody suggested to also remove the attribute from references.)

Irrespective of whether we actually want these rules, they do reflect our current requirements and code not following them risks miscompilations. As such I think we should document them here and consider them the baseline for changes to the aliasing model. It's not great to have a baseline that was never carefully reviewed or designed, but for better or worse that's where we are at.

Also incorporates rust-lang/rust#98017.

Rendered

Cc @rust-lang/lang

[CAD97]

cc also @rust-lang/wg-unsafe-code-guidelines

Just to log it, I'm weakly against merging this without also providing a solution like rust-lang/rfcs#3336 to the question of Box-just-as-a-Drop-token. Even though the struct { mem: Box<T>, ptr: &'self.mem T } pattern is currently UB, it is in practice used for lack of a reasonable¹ alternative.

At this point, though, I do strongly agree that this is the correct way to go. The optimizations that these requirements provide are significant.

musings about the future

I also think that Vec should get the same treatment as Box (though noting so can be deferred until later) even though IIRC there is more code misusing Vec (including stdlib) than Box (in part because miri doesn't complain about Vec (yet)), although I no longer think this is a hard requirement. (However, if we do make Vec enforce uniqueness even when not reallocating, then I expect we'll need to expose some form of RawVec which doesn't in order to cover the gap.)

This definitely does make Rust unsafe significantly more treacherous to use than C, but noalias analysis is getting better to the point where Rust could be more performant than C (without restrict) while also being safer. If we manage to make working with raw pointers more ergonomic to the point where it's not significantly worse than C, then a simple first-order rule of "if you're managing an object with raw pointers, only use raw pointers" prevents the issues of mixing strong references and permissive pointers.

Footnotes

1. into_rawing the owner is possible but makes interacting with the type much more difficult. ↩

[CAD97]

... Does this apply to Box? (The intent is obviously no, but what about for what we're telling LLVM?)

Because it's obviously safe to deallocate a Box allocation within a function,

fn example(x: Box<Data>) {
    drop(x);
    // here -- is `x` still considered `dereferencable`?
}

does this mean that Box needs to be marked with the hypothetical LLVM-dereferenceable_on_entry instead of just LLVM-dereferenceable? I suspect this is a nonissue in practice (memory allocation is either a very side-effectful built-in or an opaque environment call preventing code motion over it) but it's definitely relevant.

[RalfJung]

See rust-lang/rust#66600 (linked in the PR description) :)

But I will clarify the text, thanks!

[RalfJung]

I'm weakly against merging this without also providing a solution like rust-lang/rfcs#3336

So now we have a circular dependency. 😂 I opened this because that RFC has a diff for what it does to the reference, and the diff used to include the clarifications of this PR, which is misleading since that part is not new from the RFC. So I think this here needs to be merged for that RFC to even be able to discuss the aliasing rules in the level of detail that is needed to say what MaybeDangling does. We need a baseline to describe what that RFC changes.

Also as I said above, for better or worse, what this PR describes is the baseline that future changes will have to compare against. Not merging this PR won't make any code less likely to break.

Basically, this PR is descriptive in nature, not prescriptive. It describes the world as it is, whether we like it or not. We can change the world later, but first we need to agree on where we are.

[joshtriplett]

Would it be legal to take a &mut, turn it into a *mut, free it, reallocate something at the same address, and then use the &mut?

[JakobDegen]

No. LLVM recognizes allocation level provenance, meaning the resulting &mut would not have provenance for the new allocation, regardless of address

[nikomatsakis]

@rfcbot fcp merge

We discussed this in the @rust-lang/lang meeting today and arrived at the consensus that it was a good idea to describe current behavior, with the caveat that some of what we define as UB here may become legal behavior in the future (perhaps via language changes, or as part of adopting a more precise operational semantics).

[rfcbot]

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

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

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!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Checking my box for documenting the current behavior. Not committing to wanting this to be the long-term behavior; I expect to have further thoughts on the associated RFC.

[RalfJung]

@joshtriplett your box isn't checked though?

Not committing to wanting this to be the long-term behavior

I assume you specifically mean the "outlives the function call" part? Yes I do expect that to be an important point in a future discussion, when we are ready to start deciding on actual aliasing model details. This is usually a knob that is fairly easy to turn (we can just have or not have that specific rule without surprising interactions elsewhere), but it has a lot of consequences for LLVM attributes and MIR optimizations.

[Havvy]

@joshtriplett Your box is still unchecked. Is that intentional?

[joshtriplett]

Not sure why my checkbox didn't stick. Transient network issue? Checked now, in any case.

[RalfJung]

So FCP should start now, right? "Once a majority of reviewers approve (and at most 2 approvals are outstanding)"... let's see if the bot jumps into action...

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @nikomatsakis, I wasn't able to add the final-comment-period label, please do so.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

psst @nikomatsakis, I wasn't able to add the finished-final-comment-period label, please do so.

[ehuss]

Thanks!