diff options
| author | Stuart Cook <Zalathar@users.noreply.github.com> | 2025-07-29 16:16:42 +1000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-07-29 16:16:42 +1000 |
| commit | e146ab281a80199f455297218991e6b05102b943 (patch) | |
| tree | 28dfc640ce2fafaa68a70c637be6e2370c463e3e /tests/rustdoc-js-std/parser-errors.js | |
| parent | 3a3db990f6403047b1b421330ca242c91f5d5c21 (diff) | |
| parent | d12ecde365efcf6ee4eb74fb6cfdd8314ab9fec4 (diff) | |
| download | rust-e146ab281a80199f455297218991e6b05102b943.tar.gz rust-e146ab281a80199f455297218991e6b05102b943.zip | |
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: https://github.com/rust-lang/rust/issues/144538 Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
Diffstat (limited to 'tests/rustdoc-js-std/parser-errors.js')
0 files changed, 0 insertions, 0 deletions