const_eval_select: make it safe but be careful with what we expose on stable for now by RalfJung · Pull Request #121894 · rust-lang/rust

RalfJung · 2024-03-02T11:55:36Z

As this is all still nightly-only I think @rust-lang/wg-const-eval can do that without involving t-lang.

r? @oli-obk
Cc @Nilstrieb -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable const fn

… stable for now

library/core/src/intrinsics.rs

Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>

oli-obk · 2024-03-05T06:06:30Z

@bors r+ rollup

bors · 2024-03-05T06:06:33Z

📌 Commit d858809 has been approved by oli-obk

It is now in the queue for this repository.

tgross35 · 2024-03-05T09:56:35Z

library/core/src/ffi/c_str.rs

        // violated, which is UB.
-        unsafe { intrinsics::const_eval_select((bytes,), const_impl, rt_impl) }
+        unsafe {
+            intrinsics::const_eval_select((bytes,), const_impl, rt_impl)
+        }


Rustfmt changes block wrapping based on whether there is an attribute? 🤔

Seems like it 🤷

Weird, asked about it here rust-lang/rustfmt#6106

const_eval_select: make it safe but be careful with what we expose on stable for now As this is all still nightly-only I think `@rust-lang/wg-const-eval` can do that without involving t-lang. r? `@oli-obk` Cc `@Nilstrieb` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`

const_eval_select: make it safe but be careful with what we expose on stable for now As this is all still nightly-only I think ``@rust-lang/wg-const-eval`` can do that without involving t-lang. r? ``@oli-obk`` Cc ``@Nilstrieb`` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`

const_eval_select: make it safe but be careful with what we expose on stable for now As this is all still nightly-only I think ```@rust-lang/wg-const-eval``` can do that without involving t-lang. r? ```@oli-obk``` Cc ```@Nilstrieb``` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121301 (errors: share `SilentEmitter` between rustc and rustfmt) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#121905 (Add a `description` field to target definitions) - rust-lang#122022 (loongarch: add frecipe and relax target feature) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup

const_eval_select: make it safe but be careful with what we expose on stable for now As this is all still nightly-only I think ````@rust-lang/wg-const-eval```` can do that without involving t-lang. r? ````@oli-obk```` Cc ````@Nilstrieb```` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121832 (Add new Tier-3 target: `loongarch64-unknown-linux-musl`) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#121894 - RalfJung:const_eval_select, r=oli-obk const_eval_select: make it safe but be careful with what we expose on stable for now As this is all still nightly-only I think `````@rust-lang/wg-const-eval````` can do that without involving t-lang. r? `````@oli-obk````` Cc `````@Nilstrieb````` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`

tgross35 · 2024-03-06T04:52:10Z

Does this mean that using const_eval_select is okay in library code now (i.e. I can update CStr), or is that policy still yet to come?

RalfJung · 2024-03-06T07:10:18Z

@tgross35 I hope the docs are clear enough, let me know if further clarification is needed.

    /// Rust has not yet decided that `const fn` are allowed to tell whether
    /// they run at compile-time or at runtime. Therefore, when using this
    /// intrinsic anywhere that can be reached from stable, it is crucial that
    /// the end-to-end behavior of the stable `const fn` is the same for both
    /// modes of execution. (Here, Undefined Behavior is considered "the same"
    /// as any other behavior, so if the function exhibits UB at runtime then
    /// it may do whatever it wants at compile-time.)

tgross35 · 2024-03-06T07:13:48Z

Should have read the PR, thanks

rustbot assigned oli-obk Mar 2, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 2, 2024

RalfJung mentioned this pull request Mar 2, 2024

Distinguish between library and lang UB in assert_unsafe_precondition #121662

Merged