
Description
I have code in a crate in a workspace which falls afoul of clippy::map_err_ignore
(or clippy::map-err-ignore
, I've tried with both names), e.g.
// dummy example, my actual code isn't this stupid
fn main() {
let _result = std::fs::read_to_string("/etc/hostname").map_err(|_| String::new("can't read"));
}
I run the following cargo clippy
command:
cargo clippy --workspace --all-targets -- \
-D warnings \
-D clippy::pedantic \
-A clippy::map_err_ignore \
-A clippy::cast_precision_loss \
-A clippy::cast_possible_truncation \
-A clippy::cast_possible_wrap \
-A clippy::cast_sign_loss \
-A clippy::must_use_candidate \
-A clippy::missing_errors_doc \
-A clippy::if_not_else \
-A clippy::enum_glob_use
As you can see, I deny any warning or pedantic lint, but specifically allow some choices (including clippy::map_err_ignore
, also tried with hyphens rather than underscores). This works fine, except for the map_err_ignore
lint. In this case the cargo clippy
command emits warnings like the following
warning: `map_err(|_|...` ignores the original error
--> /workspaces/amoeba/software/vehicle/data/workspace/crypt/src/lib.rs:109:63
|
2 | let _result = std::fs::read_to_string("/etc/hostname").map_err(|_| String::new("can't read"));
| ^^^
|
= note: `-W clippy::map-err-ignore` implied by `-W clippy::pedantic`
= help: Consider wrapping the error in an enum variant
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_err_ignore
It seems like this is neither following the -D clippy::pedantic
flag, nor the -A clippy::map_err_ignore
flag, but has somehow inferred -W clippy::map-err-ignore
via -W clippy::pedantic
, neither of which were specified.
This behaviour does not show up for any of the other lints I specified.
I'm a bit confused about this. Seems most likely that I've made a stupid mistake somewhere, but if so I'm completely blind to it.
Meta
cargo clippy -V
:clippy 0.0.212 (7eac88a 2020-11-16)
rustc -Vv
:rustc 1.48.0 (7eac88abb 2020-11-16) binary: rustc commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4 commit-date: 2020-11-16 host: x86_64-unknown-linux-gnu release: 1.48.0 LLVM version: 11.0