Mention S-inactive-closed PRs in the CONTRIBUTING.md
Some of these PRs would be great if they could be completed. But I guess no-one would look through closed PRs if they want to contribute. Let's point (new) contributors there by mentioning these PRs in the `CONTRIBUTING.md`
base tests: switch to nightly toolchain before checking formatting of tests with rustfmt
this errored because rustfmt is not available on the master toolchain
Fix false positives for `implicit_return` and `empty_loop` on macro expansion.
This PR only fixes `implicit_return` and `empty_loop`.
But I suspect this bug may affect a lot of other lints.
rustc_tools_util: changes in preparation of release on crates.io
I want to release my [cargo-cache](https://github.com/matthiaskrgr/cargo-cache) crate on crates.io however it depends on rustc_tools_util, thus I need to publish rustc_tools_util on crates.io first.
This PR expands the Cargo.toml and adds a readme.
Teach `suspicious_else_formatting` about `if .. {..} {..}`
We essentially treat bare blocks `{..}` identically to `if .. {..}`, except for different lint messages.
Fixes#3044
panic at map_unit_fn.rs:202 for map() without args
map_unit_fn.rs accessed map() arguments before type check which ensures type is Option or Result.
Boiled it down to a simple test case.
FWIW: Found this panic when running clippy against code which used a gtk::Window's map() fn inherited from gtk::WidgetExt http://gtk-rs.org/docs/gtk/trait.WidgetExt.html#tymethod.map
There is no map_unit_fn.rs whose output would be diffed with map_unit_fn.stderr
map_unit_fn.stderr was renamed 8 months ago from option_map_unit_fn.stderr
but option_map_unit_fn.{stderr,rs} both remain and are in use.
Link to `rustc_driver` crate in plugin
This is in anticipation for rust-lang/rust#56987 where the
`rustc_driver` crate being linked in will be required to link correctly
against the compiler. In the meantime it should be harmless otherwise!
This is in anticipation for rust-lang/rust#56987 where the
`rustc_driver` crate being linked in will be required to link correctly
against the compiler. In the meantime it should be harmless otherwise!
mutex_atomic: Correct location of AtomicBool and friends
The AtomicBool, AtomicUsize, and friends, types live in the
`std::sync::atomic` module, rather than `std::atomic` as the lint
help text used to say.
