-
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
adjust const_eval_select documentation #91325
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
I started adjusting the This is a problem, because Put differently, we basically have to pick one of the two options:
|
Here's an example of how to cause UB by assuming (just in a library, not as the compiler) that a #![feature(const_align_offset)]
use std::hint::unreachable_unchecked;
// Crate A
pub const fn inconsistent() -> usize {
(&13 as *const i32).align_offset(2)
}
// Crate B
pub fn main() {
const X: usize = inconsistent();
let x = inconsistent();
if x != X { unsafe { unreachable_unchecked(); }}
} |
I mostly copied the documentation from a previous PR. (#64683) |
@bors r+ rollup |
📌 Commit 85558ad has been approved by |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
adjust const_eval_select documentation "The Rust compiler assumes" indicates that this is language UB, but [I don't think that is a good idea](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const_eval_select.20assumptions). This UB would be very hard to test for and looks like a way-too-big footgun. `@oli-obk` suggested this is meant to be more like "library UB", so I tried to adjust the docs accordingly. I also removed all references to "referential transparency". That is a rather vague concept used to mean many different things, and I honestly have no idea what exactly is meant by it in this specific instance. But I assume `@fee1-dead` had in their mind a property that all `const fn` code upholds, so by demanding that the runtime code and the const-time code are *observably equivalent*, whatever that property is would also be enforced here. Cc `@rust-lang/wg-const-eval`
…askrgr Rollup of 10 pull requests Successful merges: - rust-lang#90407 (Document all public items in `rustc_incremental`) - rust-lang#90897 (Fix incorrect stability attributes) - rust-lang#91105 (Fix method name reference in stream documentation) - rust-lang#91325 (adjust const_eval_select documentation) - rust-lang#91470 (code-cov: generate dead functions with private/default linkage) - rust-lang#91482 (Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s) - rust-lang#91524 (Fix Vec::extend_from_slice docs) - rust-lang#91575 (Fix ICE on format string of macro with secondary-label) - rust-lang#91625 (Remove redundant [..]s) - rust-lang#91646 (Fix documentation for `core::ready::Ready`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
"The Rust compiler assumes" indicates that this is language UB, but I don't think that is a good idea. This UB would be very hard to test for and looks like a way-too-big footgun. @oli-obk suggested this is meant to be more like "library UB", so I tried to adjust the docs accordingly.
I also removed all references to "referential transparency". That is a rather vague concept used to mean many different things, and I honestly have no idea what exactly is meant by it in this specific instance. But I assume @fee1-dead had in their mind a property that all
const fn
code upholds, so by demanding that the runtime code and the const-time code are observably equivalent, whatever that property is would also be enforced here.Cc @rust-lang/wg-const-eval