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.
Revert "Merge pull request #3257 from o01eg/remove-sysroot"
This reverts commit 041c49c1ed, reversing
changes made to 1df5766cbb.
The PR broke running a cargo-install'd clippy.
The installed clippy would not be able to find a crate for std.
Fixes#3523Reopens#2874
Implements lint for order comparisons against bool (#3438)
As described on issue #3438, this change implements linting for `>` and `<` comparisons against both `boolean` literals and between expressions.
Fix `implicit_return` false positives.
Fixing some false positives on the `implicit_return` lint.
Basically it should only check for missing return statements in `block.stmts.last()` if it's a `break`, otherwise it should skip because it would either be an error, or a false positive in the case of a `loop` (which I'm trying to fix with this PR).
**Question:**
- I say "we" inside of comments ([`// make sure it's a break, otherwise we want to skip`](https://github.com/rust-lang/rust-clippy/pull/3555/files#diff-11d233fe8c8414214c2b8732b8c9877aR71)). Any alternatives or is that okay?
- I named a test [`test_loop_with_nests()`](6870638c3f/tests/ui/implicit_return.rs (L54-L64)), any better suggestions?
