…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