-
Notifications
You must be signed in to change notification settings - Fork 13.6k
constify with_exposed_provenance #144539
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
constify with_exposed_provenance #144539
Conversation
Yea, I think the current documentation on @bors r+ rollup r? oli-obk |
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc `@rust-lang/wg-const-eval` `@rust-lang/opsem`
Rollup of 11 pull requests Successful merges: - #143289 (Remove `[T]::array_chunks(_mut)`) - #143883 (Add `--link-targets-dir` argument to linkchecker) - #144034 (tests: Test line number in debuginfo for diverging function calls) - #144236 (Add `core::mem::DropGuard`) - #144268 (Add method `find_ancestor_not_from_macro` and `find_ancestor_not_from_extern_macro` to supersede `find_oldest_ancestor_in_same_ctxt`) - #144303 (Consolidate staging for `rustc_private` tools) - #144539 (constify with_exposed_provenance) - #144569 (rustc-dev-guide subtree update) - #144573 (Raw Pointers are Constant PatKinds too) - #144578 (Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.) - #144582 (fix `Atomic*::as_ptr` wording) r? `@ghost` `@rustbot` modify labels: rollup
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc ``@rust-lang/wg-const-eval`` ``@rust-lang/opsem``
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc ```@rust-lang/wg-const-eval``` ```@rust-lang/opsem```
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc ````@rust-lang/wg-const-eval```` ````@rust-lang/opsem````
Rollup of 11 pull requests Successful merges: - #143883 (Add `--link-targets-dir` argument to linkchecker) - #144236 (Add `core::mem::DropGuard`) - #144303 (Consolidate staging for `rustc_private` tools) - #144367 (Move dist-apple-various from x86_64 to aarch64) - #144539 (constify with_exposed_provenance) - #144569 (rustc-dev-guide subtree update) - #144573 (Raw Pointers are Constant PatKinds too) - #144575 (fixed typo chunks->as_chunks) - #144578 (Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.) - #144582 (fix `Atomic*::as_ptr` wording) - #144616 (coverage: Regression test for "function name is empty" bug) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 10 pull requests Successful merges: - #143883 (Add `--link-targets-dir` argument to linkchecker) - #144236 (Add `core::mem::DropGuard`) - #144367 (Move dist-apple-various from x86_64 to aarch64) - #144539 (constify with_exposed_provenance) - #144569 (rustc-dev-guide subtree update) - #144573 (Raw Pointers are Constant PatKinds too) - #144575 (fixed typo chunks->as_chunks) - #144578 (Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.) - #144582 (fix `Atomic*::as_ptr` wording) - #144616 (coverage: Regression test for "function name is empty" bug) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #144539 - RalfJung:const_with_exposed_provenance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: #144538 Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
…ance, r=oli-obk constify with_exposed_provenance We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs. Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB. Tracking: rust-lang#144538 Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
Rollup of 10 pull requests Successful merges: - rust-lang/rust#143883 (Add `--link-targets-dir` argument to linkchecker) - rust-lang/rust#144236 (Add `core::mem::DropGuard`) - rust-lang/rust#144367 (Move dist-apple-various from x86_64 to aarch64) - rust-lang/rust#144539 (constify with_exposed_provenance) - rust-lang/rust#144569 (rustc-dev-guide subtree update) - rust-lang/rust#144573 (Raw Pointers are Constant PatKinds too) - rust-lang/rust#144575 (fixed typo chunks->as_chunks) - rust-lang/rust#144578 (Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.) - rust-lang/rust#144582 (fix `Atomic*::as_ptr` wording) - rust-lang/rust#144616 (coverage: Regression test for "function name is empty" bug) r? `@ghost` `@rustbot` modify labels: rollup
We allow
int as ptr
in const, so it only makes sense to also allow this function. Otherwise,const fn
can't be ported to use the more explicit exposed provenance APIs.Note that as of today,
with_exposed_provenance
in const is equivalent towithout_provenance
. However, we probably don't want to promise that: if someone doeswith_exposed_provenance(MMIO_ADDR)
in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same withwithout_provenance
then I would consider that UB.Tracking: #144538
Cc @rust-lang/wg-const-eval @rust-lang/opsem