A way forward for pointer equality in const eval#73398
A way forward for pointer equality in const eval#73398bors merged 7 commits intorust-lang:masterfrom
Conversation
This comment has been minimized.
This comment has been minimized.
ea4d8b4 to
e0c0a23
Compare
|
r? @RalfJung for the miri changes and general scheme. I'll find someone to review everything else once we both can agree on a design |
1da7834 to
217021e
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #73504) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@bors r=varkor,RalfJung,nagisa |
|
📌 Commit e465b22 has been approved by |
…,RalfJung,nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc rust-lang#53020
…,RalfJung,nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc rust-lang#53020
…,RalfJung,nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc rust-lang#53020
…arth Rollup of 9 pull requests Successful merges: - rust-lang#72271 (Improve compiler error message for wrong generic parameter order) - rust-lang#72493 ( move leak-check to during coherence, candidate eval) - rust-lang#73398 (A way forward for pointer equality in const eval) - rust-lang#73472 (Clean up E0689 explanation) - rust-lang#73496 (Account for multiple impl/dyn Trait in return type when suggesting `'_`) - rust-lang#73515 (Add second message for LiveDrop errors) - rust-lang#73567 (Clarify --extern documentation.) - rust-lang#73572 (Fix typos in doc comments) - rust-lang#73590 (bootstrap: no `config.toml` exists regression) Failed merges: r? @ghost
This commit includes work-arounds for the following changes in the compiler: - Raw pointers as const generic parameters are now forbidden. <rust-lang/rust#73398> This means the work-around for ICE caused by `&'static [_]` const generic parameters doesn't work anymore. An alternative work-around is yet to be implemented. - Mutable references are now forbidden in all constant contexts except for `const fn`s. <rust-lang/rust#72934> Working around this change was as easy as mechanically replacing `const` with `const fn` for most cases. The only tricky case was the definition of `id_map` inside `build!`, which is a macro meant to be called inside a `const` item. The type of `id_map` isn't explicitly specified but is rather implied by a given configuration function, so this couldn't be mechanically replaced with a `const` item. To resolve this problem, I added an explicit type to `build!`'s signature.
Fix ptr doc warnings. rust-lang#73398 added some stray backtick lines which cause warnings when the docs are built.
Fix ptr doc warnings. rust-lang#73398 added some stray backtick lines which cause warnings when the docs are built.
Fix ptr doc warnings. rust-lang#73398 added some stray backtick lines which cause warnings when the docs are built.
Fix ptr doc warnings. rust-lang#73398 added some stray backtick lines which cause warnings when the docs are built.
|
|
||
| // While performance would suffer if `guaranteed_eq` just returned `false` | ||
| // for all arguments, correctness and return value of this function are not affected. | ||
| #[cfg(not(bootstrap))] |
There was a problem hiding this comment.
Why was this changed? This function is not const.
There was a problem hiding this comment.
Not yet, we're working towards that. I have a local branch where I'm trying to run this in -Zunleash-the-miri-inside-of-you mode.
| let offset_ptr = ptr.ptr_wrapping_signed_offset(offset_bytes, self); | ||
| self.write_scalar(offset_ptr, dest)?; | ||
| } | ||
| sym::ptr_guaranteed_eq | sym::ptr_guaranteed_ne => { |
There was a problem hiding this comment.
I just realized that this implementation will also be used by Miri, which is a bug. Can we somehow make it be used only during CTCE?
There was a problem hiding this comment.
doesn't miri fall back to this only if it has no own impl? So we can just give miri an impl that behaves differently.
There was a problem hiding this comment.
Miri prefers the CTFE impls, to make sure we test those properly.
I am working on a PR that adds these to Miri in a way that it prefers its own impls.
…r=oli-obk Add some `const_compare_raw_pointers`-related regression tests Closes rust-lang#71381 Closes rust-lang#71382 Closes rust-lang#71611 Closes rust-lang#72352 r? @oli-obk, the author of rust-lang#73398
r? @varkor on the first commit and @RalfJung on the second commit
cc #53020