rust/tests/ui/non_expressive_names.rs
Joshua Nelson ac9dd36856 Don't abort compilation after giving a lint error
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise

This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
2021-11-08 01:22:28 +00:00

59 lines
1.1 KiB
Rust

#![warn(clippy::all)]
#![allow(unused, clippy::println_empty_string, non_snake_case)]
#[derive(Clone, Debug)]
enum MaybeInst {
Split,
Split1(usize),
Split2(usize),
}
struct InstSplit {
uiae: usize,
}
impl MaybeInst {
fn fill(&mut self) {
#[allow(non_fmt_panics)]
let filled = match *self {
MaybeInst::Split1(goto1) => panic!("1"),
MaybeInst::Split2(goto2) => panic!("2"),
_ => unimplemented!(),
};
unimplemented!()
}
}
fn underscores_and_numbers() {
let _1 = 1; //~ERROR Consider a more descriptive name
let ____1 = 1; //~ERROR Consider a more descriptive name
let __1___2 = 12; //~ERROR Consider a more descriptive name
let _1_ok = 1;
}
fn issue2927() {
let args = 1;
format!("{:?}", 2);
}
fn issue3078() {
#[allow(clippy::single_match)]
match "a" {
stringify!(a) => {},
_ => {},
}
}
struct Bar;
impl Bar {
fn bar() {
let _1 = 1;
let ____1 = 1;
let __1___2 = 12;
let _1_ok = 1;
}
}
fn main() {}