-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rename ptr::from_exposed_addr -> ptr::with_exposed_provenance #122935
Conversation
The Miri subtree was changed cc @rust-lang/miri Portable SIMD is developed in its own repository. If possible, consider making this change to rust-lang/portable-simd instead. |
This comment has been minimized.
This comment has been minimized.
320f087
to
3bb91ff
Compare
This PR changes MIR cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras |
This comment has been minimized.
This comment has been minimized.
597995b
to
a5b889a
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
a5b889a
to
038e7c6
Compare
Some changes occurred to the platform-builtins intrinsics. Make sure the cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake |
@bors r+ |
Rollup of 5 pull requests Successful merges: - rust-lang#122865 (Split hir ty lowerer's error reporting code in check functions to mod errors.) - rust-lang#122935 (rename ptr::from_exposed_addr -> ptr::with_exposed_provenance) - rust-lang#123182 (Avoid expanding to unstable internal method) - rust-lang#123203 (Add `Context::ext`) - rust-lang#123380 (Improve bootstrap comments) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#122935 - RalfJung:with-exposed-provenance, r=Amanieu rename ptr::from_exposed_addr -> ptr::with_exposed_provenance As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066). The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".) The new name nicely matches `ptr::without_provenance`.
Rename `expose_addr` to `expose_provenance` `expose_addr` is a bad name, an address is just a number and cannot be exposed. The operation is actually about the provenance of the pointer. This PR thus changes the name of the method to `expose_provenance` without changing its return type. There is sufficient precedence for returning a useful value from an operation that does something else without the name indicating such, e.g. [`Option::insert`](https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.insert) and [`MaybeUninit::write`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.write). Returning the address is merely convenient, not a fundamental part of the operation. This is implied by the fact that integers do not have provenance since ```rust let addr = ptr.addr(); ptr.expose_provenance(); let new = ptr::with_exposed_provenance(addr); ``` must behave exactly like ```rust let addr = ptr.expose_provenance(); let new = ptr::with_exposed_provenance(addr); ``` as the result of `ptr.expose_provenance()` and `ptr.addr()` is the same integer. Therefore, this PR removes the `#[must_use]` annotation on the function and updates the documentation to reflect the important part. ~~An alternative name would be `expose_provenance`. I'm not at all opposed to that, but it makes a stronger implication than we might want that the provenance of the pointer returned by `ptr::with_exposed_provenance`[^1] is the same as that what was exposed, which is not yet specified as such IIUC. IMHO `expose` does not make that connection.~~ A previous version of this PR suggested `expose` as name, libs-api [decided on](rust-lang#122964 (comment)) `expose_provenance` to keep the symmetry with `with_exposed_provenance`. CC `@RalfJung` r? libs-api [^1]: I'm using the new name for `from_exposed_addr` suggested by rust-lang#122935 here.
Rollup merge of rust-lang#122964 - joboet:pointer_expose, r=Amanieu Rename `expose_addr` to `expose_provenance` `expose_addr` is a bad name, an address is just a number and cannot be exposed. The operation is actually about the provenance of the pointer. This PR thus changes the name of the method to `expose_provenance` without changing its return type. There is sufficient precedence for returning a useful value from an operation that does something else without the name indicating such, e.g. [`Option::insert`](https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.insert) and [`MaybeUninit::write`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.write). Returning the address is merely convenient, not a fundamental part of the operation. This is implied by the fact that integers do not have provenance since ```rust let addr = ptr.addr(); ptr.expose_provenance(); let new = ptr::with_exposed_provenance(addr); ``` must behave exactly like ```rust let addr = ptr.expose_provenance(); let new = ptr::with_exposed_provenance(addr); ``` as the result of `ptr.expose_provenance()` and `ptr.addr()` is the same integer. Therefore, this PR removes the `#[must_use]` annotation on the function and updates the documentation to reflect the important part. ~~An alternative name would be `expose_provenance`. I'm not at all opposed to that, but it makes a stronger implication than we might want that the provenance of the pointer returned by `ptr::with_exposed_provenance`[^1] is the same as that what was exposed, which is not yet specified as such IIUC. IMHO `expose` does not make that connection.~~ A previous version of this PR suggested `expose` as name, libs-api [decided on](rust-lang#122964 (comment)) `expose_provenance` to keep the symmetry with `with_exposed_provenance`. CC `@RalfJung` r? libs-api [^1]: I'm using the new name for `from_exposed_addr` suggested by rust-lang#122935 here.
…r=Amanieu rename ptr::from_exposed_addr -> ptr::with_exposed_provenance As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066). The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".) The new name nicely matches `ptr::without_provenance`.
…r=Amanieu rename ptr::from_exposed_addr -> ptr::with_exposed_provenance As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066). The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".) The new name nicely matches `ptr::without_provenance`.
- rust-lang/rust#120131: Add support to `Pat` pattern type - rust-lang/rust#122935: Rename CastKind::PointerWithExposedProvenance - rust-lang/rust#123097: Adapt to changes to local_def_path_hash_to_def_id
Related changes: - rust-lang/rust#118310: Add `Ord::cmp` for primitives as a `BinOp` in MIR - rust-lang/rust#120131: Add support to `Pat` pattern type - rust-lang/rust#122935: Rename CastKind::PointerWithExposedProvenance - rust-lang/rust#123097: Adapt to changes to local_def_path_hash_to_def_id Resolves #3130, #3142
Related changes: - rust-lang/rust#118310: Add `Ord::cmp` for primitives as a `BinOp` in MIR - rust-lang/rust#120131: Add support to `Pat` pattern type - rust-lang/rust#122935: Rename CastKind::PointerWithExposedProvenance - rust-lang/rust#123097: Adapt to changes to local_def_path_hash_to_def_id Resolves model-checking#3130, model-checking#3142
rust-lang/rust#122935 changed the function name
Related changes: - rust-lang/rust#118310: Add `Ord::cmp` for primitives as a `BinOp` in MIR - rust-lang/rust#120131: Add support to `Pat` pattern type - rust-lang/rust#122935: Rename CastKind::PointerWithExposedProvenance - rust-lang/rust#123097: Adapt to changes to local_def_path_hash_to_def_id Resolves model-checking#3130, model-checking#3142
As discussed on Zulip.
The old name,
from_exposed_addr
, makes little sense as it's not the address that is exposed, it's the provenance. (ptr.expose_addr()
stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".)The new name nicely matches
ptr::without_provenance
.