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 (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation15 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
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
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Co-authored-by: bjorn3 17426603+bjorn3@users.noreply.github.com
📌 Commit d858809 has been approved by oli-obk
It is now in the queue for this repository.
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
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) |
| } |
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? 🤔
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it 🤷
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
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
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
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
…iaskrgr
Rollup of 9 pull requests
Successful merges:
- rust-lang#121065 (Add basic i18n guidance for
Display) - rust-lang#121301 (errors: share
SilentEmitterbetween 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
descriptionfield 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
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
bors added a commit to rust-lang-ci/rust that referenced this pull request
bors added a commit to rust-lang-ci/rust that referenced this pull request
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
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
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?
@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.)
Should have read the PR, thanks
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.