-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Unstably allow assume intrinsic in const contexts #76973
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
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.