Repository navigation
Conversation
|
Some changes occurred in compiler/rustc_attr_ir cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_attr_parsing cc @jdonszelmann, @JonathanBrouwer Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in compiler/rustc_passes/src/check_attr.rs |
|
Error: Failed to set assignee to
Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip. |
|
r? RalfJung |
|
|
|
Cc @folkertdev |
39047e6 to
a0ad71b
Compare
|
Can you check that all places in the compiler that check for |
I gave a look, and I think so, but I am definitely not knowledgeable enough of compiler internals to be sure. |
ebce41f to
90416b5
Compare
|
Some changes occurred to constck cc @fee1-dead Some changes occurred to the CTFE machinery
cc @bjorn3 |
This comment has been minimized.
This comment has been minimized.
90416b5 to
c906c98
Compare
|
cc @rust-lang/clippy |
FYI after applying Ralf's suggestion git/github is much happier with the diff, and shows it as a change with a size much more representative of the actual size :-) |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
|
||
| // Intrinsics are language primitives, not regular calls, so treat them separately. | ||
| if let Some(intrinsic) = tcx.intrinsic(callee) { | ||
| // Non-backend intrinsics are language primitives, not regular calls, so treat them separately. |
There was a problem hiding this comment.
I think my idea was that backend intrinsics would always have a fallback body, but that might not necessarily be the case so... what do you think should happen here?
I think that as soon as this lands, we may as well start switching extern "llvm-intrinsic" blocks over - none of those have fallbacks.
Please include a test making sure we enforce constness matching up too.
|
Reminder, once the PR becomes ready for a review, use |
e294fce to
e18a91c
Compare
|
@rustbot ready |
This comment has been minimized.
This comment has been minimized.
e18a91c to
f28292b
Compare
This comment has been minimized.
This comment has been minimized.
f28292b to
40c3e33
Compare
| #[rustc_intrinsic(llvm = "llvm.fshl.i64")] | ||
| fn fshl(a: i64, b: i64, sh: i64) -> i64 { | ||
| (((a as i128) << 64) | (b as i128) >> sh) as i64 | ||
| } | ||
|
|
||
| fn main() { | ||
| const { fshl(1, 2, 3) }; | ||
| //~^ ERROR: cannot call non-const function `fshl` in constants [E0015] | ||
| } |
There was a problem hiding this comment.
Not sure if this is worth a test, it's just standard const checking. Would be very surprising if we allowed calling a function that's not marked as const.
More interesting is ensuring that const stability checks work properly. You could extend tests/ui/consts/const-unstable-intrinsic.rs to also check backend intrinsics.
There was a problem hiding this comment.
Removed, and added more tests to the other file.
|
Btw the PR title and description seem to still refer to an earlier version of this PR. |
40c3e33 to
62cfa98
Compare
|
cc @rust-lang/miri |
llvm = argument to rustc_intrinsic.
62cfa98 to
e6d0471
Compare
|
|
||
| impl ValidityRequirement { | ||
| pub fn from_intrinsic(intrinsic: Symbol) -> Option<Self> { | ||
| pub fn from_intrinsic(intrinsic: Intrinsic) -> Option<Self> { |
There was a problem hiding this comment.
This is strictly about Rust intrinsics so I don't think it makes sense to change the type here.
There was a problem hiding this comment.
I was surprised that the interpreter didn't need any patch here. It turns out that the interpreter has relied on the item_name rather than the name recorded in the intrinsic data, which is fine today as the two are equal, but is wrong after this PR.
So this code
rust/src/tools/miri/src/intrinsics/mod.rs
Line 54 in 101dc61
and this
will need adjustment.
There was a problem hiding this comment.
There's some logic in this file that seems wrong now
There was a problem hiding this comment.
There's logic in this crate that seems wrong now
| #[unstable(feature = "unstable", issue = "42")] | ||
| #[rustc_intrinsic(llvm = "llvm.fshl.i64")] | ||
| pub const unsafe fn fake_size_of_val_llvm<T>(x: *const T) -> usize { | ||
| 0 | ||
| } |
There was a problem hiding this comment.
Please keep the test consistent, and have no fallback body here.
I'd suggest calling it llvm_fshl or so, that seems less confusing.
| pub const unsafe fn fake_align_of_val_llvm<T>(x: *const T) -> usize { | ||
| 0 | ||
| } |
There was a problem hiding this comment.
Same here, please remove the fallback body (and pick a better name)
| pub const unsafe fn fake_align_of_val_llvm<T>(x: *const T) -> usize { | ||
| 0 | ||
| } |
There was a problem hiding this comment.
also remove this fallback body (and pick a better name)
View all comments
This is meant for usage in core::arch, to define the platform-specific LLVM intrinsics that correspond to each intrinsic.
LLM usage: I used an LLM to point me at places in the code from which to start the implementation, but I did not generate any code. The main non-trivial input from the LLM was to prevent inlining of callees annotated with rustc_llvm_intrinsic.Code has been since re-designed following @bjorn3's and @RalfJung's proposals so there's no trace of any LLM input left :-)r? RalfJ