Make it possible to correctly indent snippet_block snippets
This adds a `indent_relative_to` arg to the `{snippet,expr}_block` functions. This makes it possible to keep the correct indentation of block like suggestions.
In addition, this makes the `trim_multiline` function private and adds a `indent_of` function, to get the indentation of the first line of a span.
The suggestion of `needless_continue` cannot be made auto applicable, since it would be also necessary to remove code following the linted expression. (Well, maybe it is possible, but I don't know how to do it. Expanding the suggestion span to the last expression, that should be removed didn't work)
changelog: Improve suggestions, when blocks of code are involved
Port mitsuhiko's excessive bools lints
Closes#4 .
changelog: add `struct_excessive_bools` and `fn_params_excessive_bools` lints.
I moved is_trait_impl_item check because at first I implemented it as a late pass for some reason but then I realized it's actually an early lint. But it's a useful function to have, should I move it into a separate pr?
Do not lint `unnecessary_unwrap` in external macros
Fixes#5131
I think we shouldn't lint `{panicking, unnecessary}_unwrap` in macros, not just `assert!`.
changelog: Fix false positive in `unnecessary_unwrap`
Use `checked_sub` to avoid index out of bounds
(Fixes) #4681 (possibly)
The issue likely occurs due to `lit_snip.len() < suffix.len() + 1`. You can see similar backtrace to change it to `lit_snip.len() - suffix.len() - 1000` or something then run `cargo test --release`.
But I couldn't come up with the test so I'd leave the issue open if we want.
changelog: Fix potential ICE in `misc_early`
Tweak documentation in `multiple_crate_versions`
This example isn't reproducible now since `ctrlc` upgrades `winapi` to `0.3.x` in `3.1.1`. We should pin their versions to trigger lint correctly.
changelog: none
Fix syntax highlighting of code fences
The documentation for RESULT_EXPECT_USED includes this code:
let res: Result<usize, ()> = Ok(1);
res?;
# Ok::<(), ()>(())
Because the code fence didn't start with `rust`, the code wasn't highlighted and the line starting with `#` was displayed on the website. This is now fixed.
EDIT: I noticed that highlighting for some other lints is broken as well. It only works if the code fence looks like this:
````markdown
```rust
// ..
```
````
However, many code blocks were ignored. I un-ignored most code blocks and made them compile by adding hidden code with `#`. While doing so, I found two mistakes:
```rust
opt.map_or(None, |a| a + 1)
// instead of
opt.map_or(None, |a| Some(a + 1))
```
and
```rust
fn as_str(self) -> &str
// instead of
fn as_str(self) -> &'static str
```
changelog: none
The documentation for RESULT_EXPECT_USED includes this code:
let res: Result<usize, ()> = Ok(1);
res?;
# Ok::<(), ()>(())
Because the code fence didn't start with `rust`, the code wasn't highlighted and the line starting with `#` was displayed on the website. This is now fixed.
