Description
I tried this code:
fn main() {
let xs: [i32; 5] = [1, 2, 3, 4, 5];
let _ = &xs; // this line suppresses the `unconditional_panic` lint
let _ = xs[7];
}
I expected to see this happen:
error: this operation will panic at runtime
--> src/main.rs:4:13
|
4 | let _ = xs[7];
| ^^^^^ index out of bounds: the length is 5 but the index is 7
|
= note: `#[deny(unconditional_panic)]` on by default
Instead, this happened:
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 7', src/main.rs:4:13
Apparently, taking a shared reference of xs
will suppress the unconditional_panic
lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of xs
(which is [i32; 5]
) or modify any data in this example.
Note that
fn main() {
let xs: [i32; 5] = [1, 2, 3, 4, 5];
//let _ = &xs;
let _ = xs[7];
}
will trigger the lint properly.
Meta
rustc --version --verbose
:
rustc 1.63.0-nightly (43347397f 2022-06-23)
binary: rustc
commit-hash: 43347397f7c5ca9a670a3bb3890c7187e24a52ab
commit-date: 2022-06-23
host: x86_64-unknown-freebsd
release: 1.63.0-nightly
LLVM version: 14.0.5
Metadata
Metadata
Assignees
Labels
Area: Messages for errors, warnings, and lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: MIR optimizationsCategory: This is a bug.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.Lint: unconditional_panicMedium priorityRelevant to the compiler team, which will review and decide on the PR/issue.Performance or correctness regression from one stable version to another.