Skip to content

const_eval_select: make it safe but be careful with what we expose on stable for now #121894

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 2 commits into from
Mar 6, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Mar 2, 2024

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

@rustbot 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
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from 7a88f69 to 4dbd9a9 Compare March 2, 2024 12:11
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from 4dbd9a9 to 8369943 Compare March 2, 2024 13:25
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from 8369943 to a4bb6f6 Compare March 2, 2024 13:49
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from a4bb6f6 to b8b19d0 Compare March 2, 2024 14:14
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from b8b19d0 to 7bf60f4 Compare March 2, 2024 14:40
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the const_eval_select branch from 7bf60f4 to 374607d Compare March 2, 2024 15:09
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
@oli-obk
Copy link
Contributor

oli-obk commented Mar 5, 2024

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Mar 5, 2024

📌 Commit d858809 has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 5, 2024
Comment on lines 434 to +437
// violated, which is UB.
unsafe { intrinsics::const_eval_select((bytes,), const_impl, rt_impl) }
unsafe {
intrinsics::const_eval_select((bytes,), const_impl, rt_impl)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like it 🤷

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
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`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
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`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 5, 2024
…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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 5, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 5, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 6, 2024
…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
@bors bors merged commit 327842b into rust-lang:master Mar 6, 2024
@rustbot rustbot added this to the 1.78.0 milestone Mar 6, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 6, 2024
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
Copy link
Contributor

tgross35 commented Mar 6, 2024

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 RalfJung deleted the const_eval_select branch March 6, 2024 07:07
@RalfJung
Copy link
Member Author

RalfJung commented Mar 6, 2024

@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
Copy link
Contributor

tgross35 commented Mar 6, 2024

Should have read the PR, thanks

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants