`expr.rs` index out of bounds: `the len is 0 but the index is 0` about rust

[gurry]

Thanks @compiler-errors. Just want to add that some other intrinsics also ICE.

For example:

fn main() {
    read_via_copy();
}

extern "rust-intrinsic" fn read_via_copy() {}

ICEs as well.

[compiler-errors]

Please try to minimize the example as much as possible:

fn main() {
    transmute();
}

extern "rust-intrinsic" fn transmute() {}

[gurry]

@rustbot claim

[compiler-errors]

@gurry: heads up that @estebank already put up a fix

[compiler-errors]

Interesting @gurry -- I wonder if we should perhaps fix this in a less specific way than #123526. I wonder if we should instead detect that the extern "rust-intrinsic" declaration is not valid b/c feature(intrinsics) 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.

[gurry]

I wonder if we should instead detect that the extern "rust-intrinsic" declaration is not valid b/c feature(intrinsics) has not been enabled in the crate...

Even adding feature(intrinsics) does not prevent the ICE unfortunately.

It happens in lower_intrinsics.rs due to the wrong number of arguments e.g. here for read_via_copy:

rust/compiler/rustc_mir_transform/src/lower_intrinsics.rs

Lines 176 to 178 in af25253

	let [arg] = args.as_slice() else {
	span_bug!(terminator.source_info.span, "Wrong number of arguments");
	};

span_bug!(..., "Wrong number of arguments...") 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 transmute in #123526 to all intrinsics, maybe leveraging this code to know how many args are expected for any given intrinsic:

rust/compiler/rustc_hir_analysis/src/check/intrinsic.rs

Line 223 in af25253

let (n_tps, n_cts, inputs, output) = match intrinsic_name {

[gurry]

I have opened #123587

[gurry]

Looks like intrinsics are expected to ICE if used wrongly (see comment: #123587 (comment)) so #123587 I opened has been rightly closed.

But that mean that transmute 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 #123526 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 transmute consistent with other intrinsics' behaviour as noted above.

Thoughts @estebank & @compiler-errors? If you guys agree I can open a PR to remove the tainting.

[compiler-errors]

See #123603 which takes a different approach

[gurry]

Nice!