Remove `except` in suspicious_else_formatting
96c34e85 contains the fix:
This was causing two different ICEs in #3741. The first was fixed in #3925.
The second one is fixed with this commit: We just don't `expect` anymore.
If the snippet doesn't contain an `else`, we stop emitting the lint because
it's not a suspiciously formatted else anyway.
Unfortunately I wasn't able to provide a minimal test case, but I think it's
fine since it's just ignoring the `None` case now.
And ad27e3ff cleans up the lint code to use `if_chain`.
Fixes#3741 once more.
Beta changelog
Maintain a changelog for beta so the release team can easily include important additions in the release blog posts.
r? @phansch, @oli-obk
Add Marwes/combine to integration tests
repo link: https://github.com/Marwes/combine
`combine` uses a lot of macros internally, has been downloaded more than 200_000
times and is also a dependency of [`redis-rs`](https://crates.io/crates/redis).
Clippy also previously ICEd on combine in #3747 so I think it would be
good to have this crate as an integration test.
This was causing two different ICEs in #3741.
The first was fixed in #3925.
The second one is fixed with this commit: We just don't `expect`
anymore. If the snippet doesn't contain an `else`, we stop emitting the
lint because it's not a suspiciously formatted else anyway.
repo link: https://github.com/Marwes/combine
`combine` uses a lot of macros internally, has been downloaded more than 200_000
times and is also a dependency of [`redis-rs`](https://crates.io/crates/redis).
Clippy also previously ICEd on combine in #3747 so I think it would be
good to have this crate as an integration test.
Mention that -D warnings will deny ALL warnings, not just clippy warnings
If we pass `-D warnings` to clippy, it causes the build to fail if there are *any* warnings, even the ones not generated by clippy. This isn't immediately obvious when you're looking at this as someone just setting up clippy, so people might not expect this nor know how to fix it. I've added a few sentences in the README to help anyone who runs into this.
These docs are useful for anyone setting up clippy warnings to be denied during CI, but still otherwise want rustc warnings to be allowed.
I could have also changed `-D warnings` to `-D clippy::all` in the Travis configurations themselves, but I wasn't sure what you would prefer to have people use as the default.
Fix ICE in decimal_literal_representation lint
Handling the integer parsing properly instead of just unwrapping.
Note that the test is not catching the ICE because plain UI tests
[currently hide ICEs][compiletest_issue]. Once that issue is fixed, this
test would fail properly again.
Fixes#3891
[compiletest_issue]: https://github.com/laumann/compiletest-rs/issues/169
Support updated type dependent def ID getter
This PR changes all the calls to `type_dependent_defs` (with panics via `[]`) to new method `type_dependent_def_id` with more explicit `unwrap` panic.
Rust PR: https://github.com/rust-lang/rust/pull/59216
Issue author: @oli-obk
Handling the integer parsing properly instead of just unwrapping.
Note that the test is not catching the ICE because plain UI tests
[currently hide ICEs][compiletest_issue]. Once that issue is fixed, this
test would fail properly again.
[compiletest_issue]: https://github.com/laumann/compiletest-rs/issues/169
Escape a single quote in single_char_pattern hint
This PR correctly escapes single quotes in the hint for `single_char_pattern`.
For instance, the hint for `x.split("'")` was `'''`, while it should be `'\''`.
Fix `explicit_counter_loop` suggestion
#1670
This code seems to me to work, but I have two question.
* Because range expression desugared in hir, `Sugg::hir` doesn't add parenthesis to range expression. Which function is better to check range do you think, `check_for_loop_explicit_counter` or `hir_from_snippet`?
* Do you think we need to distinguish between range expression and struct expression that creates `std::ops::Range*`?
