Philipp Krones [Wed, 8 Apr 2020 13:50:23 +0000 (15:50 +0200)]
Rollup merge of #5419 - dtolnay:unreadable, r=flip1995
Downgrade unreadable_literal to pedantic
As motivated by #5418. This is the top most commonly suppressed Clippy style lint, which indicates that the community has decided they don't share Clippy's opinion on the best style of this.
I've left the lint in as pedantic, though it could be that "restriction" would be better -- I can see this lint being useful as an opt-in restriction in some codebases.
changelog: Remove unreadable_literal from default set of enabled lints
Philipp Krones [Wed, 8 Apr 2020 13:50:20 +0000 (15:50 +0200)]
Rollup merge of #5415 - nickrtorres:master, r=flip1995
Add new lint for `Result<T, E>.map_or(None, Some(T))`
Fixes #5414
PR Checklist
---
- [x] Followed lint naming conventions (the name is a bit awkward, but it seems to conform)
- [x] Added passing UI tests (including committed .stderr file)
- [x] cargo test passes locally
- [x] Executed cargo dev update_lints
- [x] Added lint documentation
- [x] Run cargo dev fmt
`Result<T, E>` has an [`ok()`](https://doc.rust-lang.org/std/result/enum.Result.html#method.ok) method that adapts a `Result<T,E>` into an `Option<T>`.
It's possible to get around this adapter by writing `Result<T,E>.map_or(None, Some)`.
This lint is implemented as a new variant of the existing [`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)
I feel like saving 10 nanoseconds from the formatting machinery isn't worth asking the programmer to insert extra `&` / `*` noise in the *vast* majority of cases. This is a pedantic lint.
changelog: Remove inefficient_to_string from default set of enabled lints
Philipp Krones [Wed, 8 Apr 2020 13:50:17 +0000 (15:50 +0200)]
Rollup merge of #5410 - dtolnay:trivially, r=flip1995
Downgrade trivially_copy_pass_by_ref to pedantic
The rationale for this lint is documented as:
> In many calling conventions instances of structs will be passed through registers if they fit into two or less general purpose registers.
I think the purported performance benefits of clippy's recommendation are overstated. This isn't worth asking people to sprinkle code with more `*``*``&``*``&` to chase the alleged performance.
This should be a pedantic lint that is disabled by default and opted in if some specific performance sensitive codebase determines that it is worthwhile.
As a reminder, a typical place that a reference to a primitive would come up is if the function is used as a filter. Triggering a performance-oriented lint on this type of code is the definition of pedantic.
```rust
fn filter(_n: &i32) -> bool {
true
}
fn main() {
let v = vec![1, 2, 3];
v.iter().copied().filter(filter).for_each(drop);
}
```
```console
warning: this argument (4 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
--> src/main.rs:1:15
|
1 | fn filter(_n: &i32) -> bool {
| ^^^^ help: consider passing by value instead: `i32`
```
changelog: Remove trivially_copy_pass_by_ref from default set of enabled lints
Philipp Krones [Wed, 8 Apr 2020 13:50:16 +0000 (15:50 +0200)]
Rollup merge of #5409 - dtolnay:letunit, r=flip1995
Downgrade let_unit_value to pedantic
Given that the false positive in #1502 is marked E-hard and I don't have much hope of it getting fixed, I think it would be wise to disable this lint by default. I have had to suppress this lint in every substantial codebase (\>100k line) I have worked in. Any time this lint is being triggered, it's always the false positive case.
The motivation for this lint is documented as:
> A unit value cannot usefully be used anywhere. So binding one is kind of pointless.
with this example:
> ```rust
> let x = {
> 1;
> };
> ```
Sure, but the author would find this out via an unused_variable warning or from `x` not being the type that they need further down. If there ends up being a type error on `x`, clippy's advice isn't going to help get the code compiling because it can only run if the code already compiles.
changelog: Remove let_unit_value from default set of enabled lints
Philipp Krones [Wed, 8 Apr 2020 13:50:15 +0000 (15:50 +0200)]
Rollup merge of #5406 - flip1995:update_lints_fix, r=flip1995
Fix update_lints
This fixes a bug in update_lints, where `internal` lints were not registered properly. This also cleans up some code. For example: The code generation functions no longer filter the lints the are given. This is now the task of the caller. This way, it is more obvious in the `replace_in_file` calls which lints will be included in which part of a file.
This also turns the lint modules private. There is no need for them to be public, since shared code should be in the utils module anyway.
And last but not least, this fixes the `register_lints` code generation, so also internal lints get registered.
Auto merge of #5429 - faern:use-assoc-int-float-consts, r=flip1995
Use assoc int and float consts instead of module level ones
changelog: Recommend primitive type associated constants instead of module level constants
In Rust 1.43 integer and float primitive types will have a number of new associated constants. For example `MAX`, `MIN` and a number of constants related to the machine representation of floats. https://github.com/rust-lang/rust/pull/68952
These new constants are preferred over the module level constants in `{core,std}::{f*, u*, i*}`. I have in the last few days made sure that the documentation in the main rust repository uses the new constants in every place I could find (https://github.com/rust-lang/rust/pull/69860, https://github.com/rust-lang/rust/pull/70782). So the next step is naturally to make the linter recommend the new constants as well.
This PR only changes two lints. There are more. But I did not want the PR to be too big. And since I have not contributed to clippy before it felt saner to start with a small PR so I see if there are any quirks. More will come later.
Philipp Krones [Tue, 7 Apr 2020 20:40:18 +0000 (22:40 +0200)]
Merge pull request #5434 from eddyb/rustup
rustup: update for the new Ty::walk interface.
The first commit fixes a portability bug in `setup-toolchain.sh`, while the second rewrites the handling of "trait impl methods" in `use_self` - even if `Ty::walk` could've still been used, it was IMO a misuse.
This could also serve as a PSA: *please* use `hir_ty_to_ty` instead of trying to compare `hir::Ty`s between themselves or against semantic `Ty`s. Its "quasi-deprecation" is 3 years old and doesn't really mean anything, just that it's currently uncached and that we should eventually querify it (either for a single HIR node, or for all of the nodes in an entire definition).
Nick Torres [Sat, 4 Apr 2020 06:59:52 +0000 (23:59 -0700)]
result_map_or_into_option: add lint to catch manually adpating Result -> Option
Result<T, E> has an `ok()` method that adapts a Result<T,E> into an Option<T>.
It's possible to get around this adapter by writing Result<T,E>.map_or(None, Some).
This lint is implemented as a new variant of the existing
[`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)
Auto merge of #5401 - dtolnay:option, r=Manishearth
Downgrade option_option to pedantic
Based on a search of my work codebase (\>500k lines) for `Option<Option<`, it looks like a bunch of reasonable uses to me. The documented motivation for this lint is:
> an optional optional value is logically the same thing as an optional value but has an unneeded extra level of wrapping
which seems a bit bogus in practice. For example a typical usage would look like:
```rust
let mut host: Option<String> = None;
let mut port: Option<i32> = None;
let mut payload: Option<Option<String>> = None;
for each field {
match field.name {
"host" => host = Some(...),
"port" => port = Some(...),
"payload" => payload = Some(...), // can be null or string
_ => return error,
}
}
let host = host.ok_or(...)?;
let port = port.ok_or(...)?;
let payload = payload.ok_or(...)?;
do_thing(host, port, payload)
```
This lint seems to fit right in with the pedantic group; I don't think linting on occurrences of `Option<Option<T>>` by default is justified.
---
changelog: Remove option_option from default set of enabled lints
bors [Tue, 31 Mar 2020 15:36:54 +0000 (15:36 +0000)]
Auto merge of #5398 - flip1995:deescalate, r=Manishearth
Stop updating the lint counter with every new lint
r? @Manishearth
This PR does two things:
1. Clean up the clippy_dev module a bit (first 3 commits; cc #5394 )
2. Make the counter in the README count in steps of 50 lints. Also use a `lazy_static` `Vec` for the lint list, so no counter is required there anymore.
bors [Mon, 30 Mar 2020 19:52:41 +0000 (19:52 +0000)]
Auto merge of #5294 - tmiasko:trait-ptr-cmp, r=Manishearth
Lint unnamed address comparisons
Functions and vtables have an insignificant address. Attempts to compare such addresses will lead to very surprising behaviour. For example: addresses of different functions could compare equal; two trait object pointers representing the same object and the same type could be unequal.
Lint against unnamed address comparisons to avoid issues like those in rust-lang/rust#69757 and rust-lang/rust#54685.
changelog: New lints: [`fn_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294), [`vtable_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294)
bors [Mon, 30 Mar 2020 18:53:05 +0000 (18:53 +0000)]
Auto merge of #5373 - flip1995:doc_release_backport, r=Manishearth
Document how to create releases and backports
This PR adds documentation on how to create Clippy releases and backports.
This PR also introduces a new backport/release process for Clippy:
- A beta branch is introduced: https://github.com/rust-lang/rust-clippy/tree/beta
- Backports are now done by PRs to the `beta` branch
- also commits to the beta branch will be deployed, so that the documentation page has a tab for the Clippy beta release.
This has two advantages:
1. The Clippy release process is closer to the Rust release process: stable releases are tagged, the beta release has its own branch
2. Backports to beta are easier, since they don't need as much coordination as before. No new branch has to be created for a backport. Just a PR to the beta branch, like in the Rust repo.¹
I tested the deployment here: https://github.com/flip1995/rust-clippy/runs/534465081 and it created this commit: https://github.com/flip1995/rust-clippy/commit/734503377e5ade55864ee674c010227a780cbf34, so it works.
bors [Sun, 29 Mar 2020 18:14:38 +0000 (18:14 +0000)]
Auto merge of #5382 - richkadel:gitattributes-macro, r=phansch
git attribute macros not allowed in submodules
This change simply moves the `rust` macro definition directly into the
attributes for `*.rs` files.
git commands that recurse from the rust toplevel tree into submodules
produce errors in clippy due to the fact that:
"Custom macro attributes can be defined only in top-level
gitattributes files"
For example, from the toplevel `rust` directory in a rustc development
build, try:
$ git grep "search string" --recurse-submodules
Embedded within the actual results is the error message:
[attr]rust text eol=lf whitespace=tab-in-indent,trailing-space,tabwidth=4
not allowed: src/tools/clippy/.gitattributes:1
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.