Compiling with -C debuginfo=2 reduces warnings unexpectedly

[jyn514]

Passing -C debuginfo=2 to rustc gives fewer warnings than debuginfo={0,1}. I expected to see the same output regardless of debug symbols.

Example

 % rustc src/main.rs -C debuginfo=1
warning: this expression will panic at run-time
 --> src/main.rs:4:19
  |
4 |     let element = a[index];
  |                   ^^^^^^^^ index out of bounds: the len is 3 but the index is 10
 % rustc src/main.rs -C debuginfo=2
 % rustc src/main.rs               
warning: this expression will panic at run-time
 --> src/main.rs:4:19
  |
4 |     let element = a[index];
  |                   ^^^^^^^^ index out of bounds: the len is 3 but the index is 10

Version

% rustc --version --verbose
rustc 1.24.1 (d3ae9a9e0 2018-02-27)
binary: rustc
commit-hash: d3ae9a9e08edf12de0ed82af57ba2a56c26496ea
commit-date: 2018-02-27
host: x86_64-unknown-linux-gnu
release: 1.24.1
LLVM version: 4.0

[jyn514]

By the way, this must have existed for quite some time, because the second version of the Book does something similar without a warning from rustc.

[varkor]

I can't reproduce this on 1.26.0 — are you able to check it still occurs on nightly?

[jyn514]

Definitely present on 1.26.0.

 % rustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-2017-12-21-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.26.0-nightly (2789b067d 2018-03-06)

 % cat src/main.rs
fn main() {
    let a = [1, 2, 3];
    let index = 10;
    let element = a[index];
    println!("element is {}", element);
}
 % rustc src/main.rs -C debuginfo=2
 % rustc src/main.rs -C debuginfo=1
warning: this expression will panic at run-time
 --> src/main.rs:4:19
  |
4 |     let element = a[index];
  |                   ^^^^^^^^ index out of bounds: the len is 3 but the index is 10

[varkor]

Ah, interesting: it occurs for your test program, but not for this one (i.e. here the warning is always displayed):

fn main() {
    let a: [i32; 1] = [0; 1];
    a[1];
}

[jyn514]

Afraid I'm new to rust - is that a type annotation that a is an array of length 1 and type i32? Isn't the right side assigning an array of length 2?

[sfackler]

[0; 1] means "an array of length 1 filled with 0 values".

[varkor]

Just from a little looking around, the check here seems to be the cause:

rust/src/librustc_trans/mir/mod.rs

Lines 266 to 281 in c90f682

	let dbg = debug_scope.is_valid() && bx.sess().opts.debuginfo == FullDebugInfo;
	if !memory_locals.contains(local.index()) && !dbg {
	debug!("alloc: {:?} ({}) -> operand", local, name);
	return LocalRef::new_operand(bx.cx, layout);
	}
	debug!("alloc: {:?} ({}) -> place", local, name);
	let place = PlaceRef::alloca(&bx, layout, &name.as_str());
	if dbg {
	let (scope, span) = fx.debug_loc(decl.source_info);
	declare_local(&bx, &fx.debug_context, name, layout.ty, scope,
	VariableAccess::DirectVariable { alloca: place.llval },
	VariableKind::LocalVariable, span);
	}
	LocalRef::Place(place)

If dbg == false (i.e. debuginfo != 2), then the first return is hit and everything works. Otherwise, the returned value is constructed differently (LocalRef::Place(place)) and the warnings henceforth do not appear.

[varkor]

My suspicion is that this issue is specific to the old constant evaluation system, which has recently been completely replaced by miri. It's hard to be completely sure, because the array indexing warning has not yet been implemented in miri, but it seems very likely.

Have you spotted any other kinds of warnings that also disappear for debuginfo = 2?

[steveklabnik]

This example doesn't warn, but the one from #48920 does; and does so regardless of debuginfo level. Given @varkor's comment above, I believe that to be true as well, and so I'm closing. Let me know if you've found this behavior elsewhere!