Quick fix for the updated website theaming to access the correct css files
This fixes a problem from #7030 that the service used to access css files was blocked by GitHub pages due to `SSL_ERROR_BAD_CERT_DOMAIN`. The css file loading worked fine during local development. The browser probably disabled some security options due to the local address.
This fix works locally and should also work online as it references the direct css files used by the [mdBook User Guide](https://rust-lang.github.io/mdBook/index.html) the disadvantage of this is that refactorings within the mdBook project can have effects on the theme loading of Clippy. This PR is therefor more meant as a quick fix until I find a better solution.
I've tested these changes using the page editor in the browser and can now confirm that they work :)
changelog: none
r? `@llogiq`
Fix `redundant_clone` fp
fixes: #5973fixes: #5595fixes: #6998
changelog: Fix `redundant_clone` fp where the cloned value is modified while the clone is in use.
Internal `if_chain!` lints
changelog: none
We use `if_chain!` a lot. So this enforces some style rules around it, internal only.
Lints when...
* Nested `if`/`if_chain!` can be collapsed
* An `if_chain!` starts with `let` or ends with `let ..; then {..}`
* An `if_chain!` has only one `if`
* An `if_chain!` contains `if .. && ..;` that spans multiple lines
lintcheck: warn if we get a bad exit status while running clippy
Right now we won't notice if a crate fails to build.
Print a warning message to indicate that there is a problem of some sort.
I'll still have to do more investigation on why this actually happens.
I suspect that the problem is that `clippy fix` might run --all-targets but when we download the crate source from crates.io, some path deps (used for internal tests etc...) are not available (which is usually not a problem because the internal tests are not needed when using the crate as a lib..?)
changelog: none
Destructure args in `methods`
changelog: none
This changes the main pattern in `methods` to match and destructure the method call args at the same time as the method name, and pass individual arg `Expr`s to the lint impls.
```rust
// before
["expect", ..] => expect::check(cx, expr, arg_lists[0]);
// after
("expect", [arg]) => expect::check(cx, expr, recv, arg);
```
This makes the code safer since there is no risk of out of bounds `args[n]` everywhere. There will be no more collecting `method_names`, `arg_lists`, `method_spans` as a separate step - everything comes out of the `match`es. Chained methods are parsed in a nested `match`. This makes the code more verbose in some ways, but IMO it is much easier to follow.
~Definitely should wait for #6896. Just putting out the idea.~
Lint: filter(Option::is_some).map(Option::unwrap)
Fixes#6061
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog:
* add new lint for filter(Option::is_some).map(Option::unwrap)
First Rust PR, so I'm sure I've violated some idioms. Happy to change anything.
I'm getting one test failure locally -- a stderr diff for `compile_test`. I'm having a hard time seeing how I could be causing it, so I'm tentatively opening this in the hopes that it's an artifact of my local setup against `rustc`. Hoping it can at least still be reviewed in the meantime.
I'm gathering that since this is a method lint, and `.filter(...).map(...)` is already checked, the means of implementation needs to be a little different, so I didn't exactly follow the setup boilerplate. My way of checking for method calls seems a little too direct (ie, "is the second element of the expression literally the path for `Option::is_some`?"), but it seems like that's how some other lints work, so I went with it. I'm assuming we're not concerned about, eg, closures that just end up equivalent to `Option::is_some` by eta reduction.
