-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Intrinsics declared with wrong arg count ICE #123587
Comments
It's a bit hidden in the ICE message, understandable that you've missed it. |
Oh. I should've seen that. Thanks :) |
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.rs
e.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
transmute
intrinsic.The text was updated successfully, but these errors were encountered: