-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Unstably allow assume intrinsic in const contexts #76973
Conversation
7d25016
to
4bb75dd
Compare
4bb75dd
to
a3f87fc
Compare
a3f87fc
to
c2390c9
Compare
pub const unsafe fn foo(x: usize, y: usize) -> usize { | ||
assume(y != 0); | ||
x / y | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this the kind of test that should be made a unit test instead (#76268)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only saw const_slice_from_raw_parts
and const_raw_ptr_deref
in library/core/tests/lib.rs
.
Not really sure about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this should be a unit-test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's kind of weird since most intrinsics not tested in library/core/tests
.
Anyway, I moved it.
Not sure the block optimization concerns about adding assume to |
Because the above concern isn't resolved, I will move the |
Yea they probably do :( I don't think there's any point in summoning nagisa or hanna, I don't think anything changed over the last two years that woudl affect this. |
c2390c9
to
4387480
Compare
@bors r+ |
📌 Commit 382d724 has been approved by |
@bors rollup |
…-obk Unstably allow assume intrinsic in const contexts Not sure much about this usage because there are concerns about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic in inline functions. But since Oli suggested in rust-lang#76960 (comment), here we are. [1]: rust-lang#54995 (comment) [2]: rust-lang#49572 (comment)
…-obk Unstably allow assume intrinsic in const contexts Not sure much about this usage because there are concerns about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic in inline functions. But since Oli suggested in rust-lang#76960 (comment), here we are. [1]: rust-lang#54995 (comment) [2]: rust-lang#49572 (comment)
…as-schievink Rollup of 15 pull requests Successful merges: - rust-lang#76932 (Relax promises about condition variable.) - rust-lang#76973 (Unstably allow assume intrinsic in const contexts) - rust-lang#77005 (BtreeMap: refactoring around edges) - rust-lang#77066 (Fix dest prop miscompilation around references) - rust-lang#77073 (dead_code: look at trait impls even if they don't contain items) - rust-lang#77086 (Include libunwind in the rust-src component.) - rust-lang#77097 (Make [].as_[mut_]ptr_range() (unstably) const.) - rust-lang#77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml) - rust-lang#77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts) - rust-lang#77126 (Invalidate local LLVM cache less often) - rust-lang#77146 (Install std for non-host targets) - rust-lang#77155 (remove enum name from ImplSource variants) - rust-lang#77176 (Removing erroneous semicolon in transmute documentation) - rust-lang#77183 (Allow multiple allow_internal_unstable attributes) - rust-lang#77189 (Remove extra space from vec drawing) Failed merges: r? `@ghost`
Remove assume intrinsic from EvalContextExt Waiting for rust-lang/rust#76973 merged.
Not sure much about this usage because there are concerns
about blocking optimization and slowing down LLVM when using
assme
intrinsicin inline functions.
But since Oli suggested in #76960 (comment),
here we are.