OOB index in async fn evades linter

[fuse117]

I am hitting index out of bounds panics when indexing into arrays in macros inside aync functions. An example is the following.

async fn foo() {
    let x: [u8; 1] = [0];
    rprintln!("{:x} {:x}", x[0], x[1]);
}

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:18:34

This playground showcases the issue. The actual macro I am using is rprintln from rtt-target

[matthiaskrgr]

you have an array x of length 1 : [0]

x[0] returns the 0th / "first" element in the array and x[1] returns the 1th "second" element of the array.
This is just a classic array off-by-one bug in your code ^^

pub fn main() {
    let arr: [u8; 1] = [0];
    let _ = arr[1]; // BOOM
}

[fuse117]

Yes, I know. It is a contrived example. I would expect the compiler to catch it. Remove the async and it does. See this playground

[jamesmunns]

So, @matthiaskrgr, the issue here is that the compile time (lint? check?) DOES fire for sync code, and does NOT fire for async code. I minimized further and the macro use is not needed, it's only sync vs async:

use futures::executor::block_on;

fn main() {
    let _ = block_on(lola());
    // let _ = lol();
}

fn lol() {
    let x: [u8; 1] = [0];
    println!("{}", x[1]);
}

async fn lola() {
    let x: [u8; 1] = [0];
    println!("{}", x[1]);
}

playground link.

If you uncomment the line that calls lol(), the code no longer compiles, whereas with lola(), it is a runtime error with no warning at compile time.

[jamesmunns]

It seems this check is unconditional_panic, so perhaps it would make sense to change the title to "unconditional_panic lint does not detect out of bounds access for async functions at compile time" or similar, to make the issue more clear.

[matthiaskrgr]

Possibly there is some const propagation that shuts off as soon as it sees anything async

[saethlin]

The const prop lint is tripped up by almost anything. For example, this program doesn't produce a const prop error:

fn main() {
    let arr = [0];
    let sli = &arr[..];
    sli[1];
}

But also yes, generators are special-cased in addition:

rust/compiler/rustc_mir_transform/src/const_prop_lint.rs

Lines 58 to 64 in 4457658

	let is_generator = tcx.type_of(def_id.to_def_id()).subst_identity().is_generator();
	// FIXME(welseywiser) const prop doesn't work on generators because of query cycles
	// computing their layout.
	if is_generator {
	trace!("ConstProp skipped for generator {:?}", def_id);
	return;
	}

[vincenzopalazzo]

@rustbot claim

[vincenzopalazzo]

But also yes, generators are special-cased in addition:

Yes this is the problem, I should understand why we skip this for generators in MIR and try to fix this asp

if you compile the compiler without the code

rust/compiler/rustc_mir_transform/src/const_prop_lint.rs

Lines 58 to 64 in 4457658

	let is_generator = tcx.type_of(def_id.to_def_id()).subst_identity().is_generator();
	// FIXME(welseywiser) const prop doesn't work on generators because of query cycles
	// computing their layout.
	if is_generator {
	trace!("ConstProp skipped for generator {:?}", def_id);
	return;
	}

all works for this simple example.