NonNull's as_ref / as_mut don't have arbitrary lifetimes as stated
#80183
Labels
A-lifetimes
Area: Lifetimes / regions
A-raw-pointers
Area: raw pointers, MaybeUninit, NonNull
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
camelid
added
A-lifetimes
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Mar 21, 2021
Make NonNull::as_ref (and friends) return refs with unbound lifetimes
# Rationale:
1. The documentation for all of these functions claims that this is what the functions already do, as they all come with this comment:
> You must enforce Rust's aliasing rules, *since the returned lifetime 'a is arbitrarily chosen* and does not necessarily reflect the actual lifetime of the data...
So I think it's just a bug that they weren't this way already. Note that had it not been for this part, I wouldn't be making this PR, so if we decide we won't take this change, I'll follow it up with a docs PR to fix this.
2. This is how the equivalent raw pointer functions behave.
They also take `self` and not `&self`/`&mut self`, but that can't be changed compatibly at this point. This is the next best thing.
3. Without this fix, often code that uses these methods will find it has to expand the lifetime of the result.
(I can't speak for others but even in unsafe-heavy code, needing to do this unexpectedly is a huge red flag -- if Rust thinks something should have a specific lifetime, I assume it's for a reason)
### Can this cause existing code to be unsound?
I'm confident this can't cause new unsoundness since the reference exists for at most its lifetime, but you get a borrow checker error if you do something that would require/allow the reference to exist past its lifetime.
Additionally, the aliasing rules of a reference only applies while the reference exists.
This *must* be the case, as it is required by the rules used by safe code. (That said, the documentation in this file sort of contradicts it, but I think it's just ambiguity between the lifetime `'a` in `&'a T` and lifetime of the `&'a T` reference itself...)
We are increasing the lifetime of these references, but they should already have hard bounds on that lifetime, or they'd have borrow checker errors.
(CC `@RalfJung` because I have gone and done the mistake where I say something definitive about aliasing in Rust which is honestly outside the group of things I should make definitive comments about).
# Caveats
1. This is insta-stable (except for on the unstable functions ofc). I don't think there's any other alternative.
2. I don't believe this is a breaking change in practice. In theory someone could be assigning `NonNull::as_ref` to a function pointer of type `fn(&NonNull<T>) -> &T`. Now they'd need to use a slightly different function pointer type which is (probably) incompatible. This seems pathological, but I guess crater could be used if there are concerns.
3. This has no tests. The old version didn't either that I saw. I could add some stuff that fails to compile without it, if that would be useful.
4. Sometimes the NLL borrow checker gives up and decides lifetimes live till the end of the scope, as opposed to the range where they're used. If this change can cause this to happen more, then my soundness rationale is wrong, and it's likely breaking.
In practice this seems super unlikely.
Anyway. That was a lot of typing.
Fixes rust-lang#80183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The docs for
NonNull::as_refmention:Which makes sense, the pointer doesn't carry a lifetime with it, so we need to decide on it. However, the implementation actually looks like this (with implicit lifetimes shown for clarity):
This makes it so the reference constructed has the same lifetime as the pointer variable, which is likely not what is intended.
The same occurs for all of these methods currently:
as_refas_mutAdditionally, these unstable methods with
# also have the same problem.as_uninit_sliceas_uninit_slice_mutas_uninit_refas_uninit_mutThe text was updated successfully, but these errors were encountered: