Code change:
if tcx.fn_sig(did).skip_binder().abi() == RustIntrinsic && tcx.item_name(did) == sym::transmute { <del> let from = fn_sig.inputs().skip_binder()[0]; </del> <ins> let Some(from) = fn_sig.inputs().skip_binder().get(0) else { let e = self.dcx().span_delayed_bug( tcx.def_span(did), "intrinsic fn `transmute` defined with no parameters", ); self.set_tainted_by_errors(e); return Ty::new_error(tcx, e); }; </ins> let to = fn_sig.output().skip_binder(); // We defer the transmute to the end of typeck, once all inference vars have // been resolved or we errored. This is important as we can only check transmute // on concrete types, but the output type may not be known yet (it would only // be known if explicitly specified via turbofish). <del> self.deferred_transmute_checks.borrow_mut().push((from, to, expr.hir_id)); </del> <ins> self.deferred_transmute_checks.borrow_mut().push((*from, to, expr.hir_id)); </ins> } if !tcx.features().unsized_fn_params { // We want to remove some Sized bounds from std functions,

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --(reduced) (original) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please try to minimize the example as much as possible:
claim
heads up that already put up a fix
Thanks Just want to add that some other intrinsics also ICE. For example: ICEs as well.
Interesting -- I wonder if we should perhaps fix this in a less specific way than . I wonder if we should instead detect that the declaration is not valid b/c has not been enabled in the crate... If not, then I'd be glad to review a PR that fixes whatever other intrinsics you find to make too many assumptions in the compiler.
Even adding does not prevent the ICE unfortunately. It happens in due to the wrong number of arguments e.g. here for : occurs for a lot of intrinsics in this file. I'm guessing all of them will ICE under the conditions in this issue. To fix it, we could extend what's done for in to all intrinsics, maybe leveraging this code to know how many args are expected for any given intrinsic:
I have opened
Looks like intrinsics are expected to ICE if used wrongly (see comment: ) so I opened has been rightly closed. But that mean that should also ICE in these conditions. However, in the present issue it was ICEing for the wrong reason i.e. out of bound access . So does the right thing by stopping that. However, IMHO it should not taint the context and let it go to MIR lowering and then let it ICE there. That keeps consistent with other intrinsics' behaviour as noted above. Thoughts & If you guys agree I can open a PR to remove the tainting.
See which takes a different approach
Nice!