Intrinsics declared with wrong arg count ICE #123587
Comments
gurry
added
C-bug
rustbot
added
the
needs-triage
gurry
changed the title
It's a bit hidden in the ICE message, understandable that you've missed it. |
|
Oh. I should've seen that. Thanks :) |
jieyouxu
removed
the
needs-triage
|
Copying from #123526 (comment):
I think this ticket is a good example of a case where having a distinction between "the compiler made a mistake" and "the user modifiable language state is incorrect" in the panic output would be useful. It'd be already great if it only applied to the "expect" methods (like "assume the Sized trait is available" methods). If those weren't an automatic ICE, I think we could clean up |
|
You could replace all of the |
|
i think we should just make the ICE message here a bit clearer |
…tebank Don't even parse an intrinsic unless the feature gate is enabled Don't return true in `tcx.is_intrinsic` if the function is defined locally and `#![feature(intrinsics)]` is not enabled. This is a slightly more general fix than rust-lang#123526, since rust-lang#123587 shows that we have simplifying assumptions about intrinsics elsewhere in the compiler. This will make the code ICE again if the user **enables** `#[feature(intrinsics)]`, but I kind of feel like if we want to fix that, we should make the `INTERNAL_FEATURES` lint `Deny` again. Perhaps we could do that on non-nightly compilers. Or we should just stop compilation altogether if they have `#![feature]` enabled on a non-nightly compiler. As for the UX of *real* cases of hitting these ICEs, I believe pretty strongly that if a compiler/stdlib dev is modifying internal intrinsics (intentionally, like when making a change to rustc) we have no guarantee to make the ICE better looking for them. Honestly, *not* spitting out a stack trace is probably a disservice to the people who hit those ICEs in that case. r? `@Nilstrieb` `@estebank`
Rollup merge of rust-lang#123603 - compiler-errors:no-intrinsic, r=estebank Don't even parse an intrinsic unless the feature gate is enabled Don't return true in `tcx.is_intrinsic` if the function is defined locally and `#![feature(intrinsics)]` is not enabled. This is a slightly more general fix than rust-lang#123526, since rust-lang#123587 shows that we have simplifying assumptions about intrinsics elsewhere in the compiler. This will make the code ICE again if the user **enables** `#[feature(intrinsics)]`, but I kind of feel like if we want to fix that, we should make the `INTERNAL_FEATURES` lint `Deny` again. Perhaps we could do that on non-nightly compilers. Or we should just stop compilation altogether if they have `#![feature]` enabled on a non-nightly compiler. As for the UX of *real* cases of hitting these ICEs, I believe pretty strongly that if a compiler/stdlib dev is modifying internal intrinsics (intentionally, like when making a change to rustc) we have no guarantee to make the ICE better looking for them. Honestly, *not* spitting out a stack trace is probably a disservice to the people who hit those ICEs in that case. r? `@Nilstrieb` `@estebank`
An ICE occurs if you declare an intrinsic with the wrong number of args and then try to use it.
Code
Meta
rustc --version --verbose:Error output
Backtrace
The ICE originates in
lower_intrinsics.rse.g. over here forread_via_copy:rust/compiler/rustc_mir_transform/src/lower_intrinsics.rs
Lines 176 to 178 in af25253
Since there are a lot of occurrences of
span_bug!(..., "Wrong number of arguments...")in this file, many other intrinsics will also ICE under the given conditions.Related issue: #123442 which is a special case of this issue for the
transmuteintrinsic.The text was updated successfully, but these errors were encountered: