bors [Fri, 19 Nov 2021 13:39:08 +0000 (13:39 +0000)]
Auto merge of #7984 - phansch:disallowed-type-rename, r=xFrednet
Pluralize `disallowed_type` lint
This was brought up in [Zulip] and is also mentioned in the lint naming
conventions. Since this is still a nursery lint, I think there shouldn't
be any problem in renaming it.
bors [Thu, 18 Nov 2021 23:35:03 +0000 (23:35 +0000)]
Auto merge of #7977 - Jarcho:multi_needless_borrow, r=xFrednet
Improve `needless_borrow` lint
fixes: #5327
fixes: #1726
fixes: #1212
This is merging `needless_borrow` into the `dereference` pass in preparation for `explicit_auto_deref`. `explicit_auto_deref` needs to implement most of what `needless_borrow` implements in order to work.
There is a minor regression here where `let x: &str = &x.deref()` will trigger `needless_borrow` without triggering `explicit_deref_methods`. Removing the redundant borrow will cause `explicit_deref_methods` to trigger. This will be fixed when `explicit_auto_deref` is implemented.
changelog: Lint `needless_borrow` when a borrow is auto-derefed more than once
changelog: Lint `needless_borrow` in the trailing expression of a block for a match arm
Philipp Hansch [Wed, 17 Nov 2021 06:39:21 +0000 (07:39 +0100)]
Pluralize disallowed_type lint
This was brought up in [Zulip] and is also mentioned in the lint naming
conventions. Since this is still a nursery lint, I think there shouldn't
be any problem in renaming it.
bors [Tue, 16 Nov 2021 23:01:02 +0000 (23:01 +0000)]
Auto merge of #7982 - Blckbrry-Pi:master, r=llogiq
Fix `needless_collect`'s tendency to suggest code requiring multiple mutable borrows of the same value.
Fixes error specified in #7975.
changelog: [`needless_collect`] no longer suggests removal of `collect` when removal would create code requiring mutably borrowing a value multiple times.
Skyler Calaman [Tue, 16 Nov 2021 16:29:26 +0000 (11:29 -0500)]
Fix readability suggestions.
1. Make the lifetime contained in LateContext `'tcx`.
2. Fix `'txc` to `'tcx` because it was a typo.
3. Refactor `IterFunctionVisitor`'s `visit_block` method to be more readable.
4. Replace uses of `rustc_middle::ty::TyKind` with `rustc::middle::ty`, and remove the `#[allow(...)]`.
bors [Fri, 12 Nov 2021 18:17:18 +0000 (18:17 +0000)]
Auto merge of #7948 - 5225225:castlosslessbool, r=llogiq
Lint for bool to integer casts in `cast_lossless`
The lint description says
> Checks for casts between *numerical* types that may be replaced by safe conversion functions.
Which is strictly speaking being violated here, but it seems within the spirit of the lint. I think it is still a useful lint to have, and having a different lint for just this feels excessive. Thoughts?
Fixes #7947
changelog: Lint for bool to integer casts in [`cast_lossless`]
bors [Thu, 11 Nov 2021 19:33:06 +0000 (19:33 +0000)]
Auto merge of #7956 - camsteffen:author, r=llogiq
Author improvements
changelog: none
Various aspects of the author implementation are re-imagined to be much less repetitive. Also fixes some bugs. I hope this makes author more fun to work on for future contributors.
The last commit is pretty heavy but I tried to at least separate some changes so that the test file diffs per commit are simple.
bors [Thu, 11 Nov 2021 16:42:57 +0000 (16:42 +0000)]
Auto merge of #7643 - xFrednet:7569-splits-for-slices, r=camsteffen
New lint `index_refutable_slice` to avoid slice indexing
A new lint to check for slices that could be deconstructed to avoid indexing. This lint should hopefully prevent some panics in other projects and ICEs for us. See #7569 for an example
The implementation specifically checks for immutable bindings in `if let` statements to slices and arrays. Then it checks if these bindings are only used for value access using indices and that these indices are lower than the configured limit. I did my best to keep the implementation small, however the check was sadly quite complex. Now it's around 300 lines for the implementation and the rest are test.
---
Optional future improvements:
* Check for these instances also in `match` statements
* Check for mutable slice bindings that could also be destructed
---
changelog: New lint [`index_refutable_slice`]
I've already fixed a bunch of lint triggers in #7638 to make this PR smaller
xFrednet [Tue, 31 Aug 2021 17:17:24 +0000 (19:17 +0200)]
New `index_refutable_slice` lint
* Finding pattern slices for `avoidable_slice_indexing`
* `avoidable_slice_indexing` analysing slice usage
* Add configuration to `avoidable_slice_indexing`
* Emitting `avoidable_slice_indexing` with suggestions
* Dogfooding and fixing bugs
* Add ui-toml test for `avoidable_slice_indexing`
* Correctly suggest `ref` keywords for `avoidable_slice_indexing`
* Test and document `mut` for `avoid_slice_indexing`
* Handle macros with `avoidable_slice_indexing` lint
* Ignore slices with sub patterns in `avoidable_slice_indexing`
* Update lint description for `avoidable_slice_indexing`
* Move `avoidable_slice_indexing` to nursery
* Added more tests for `avoidable_slice_indexing`
* Update documentation and message for `avoidable_slice_indexing`
* Teach `avoidable_slice_indexing` about `HirId`s and `Visitors`
* Rename lint to `index_refutable_slice` and connected config
bors [Thu, 11 Nov 2021 12:38:04 +0000 (12:38 +0000)]
Auto merge of #7813 - xFrednet:6492-lint-version, r=flip1995
Add Clippy version to Clippy's lint list
Hey, hey, the semester is finally over, and I wanted to get back into hacking on Clippy. It has also been some time since our metadata collection monster has been feed. So, this PR adds a new attribute `clippy::version` to document which version a lint was stabilized. I considered using `git blame` but that would be very hacky and probably not accurate.
I'm also thinking that this attribute can be used to have a `clippy::nightly` lint group which is allow-by-default that delays setting the actual lint group until the defined version is reached. Just something to consider regarding #6623 :upside_down_face:
This PR only adds the version to 4 lints to keep it reviewable. I'll do a followup PR to add the version to other lints if the implementation is accepted :upside_down_face:
changelog: [Clippy's lint list](https://rust-lang.github.io/rust-clippy/master/index.html) now displays the version a lint was added. :tada:
---
Example lint declaration after this update:
```rs
declare_clippy_lint! {
/// [...]
///
/// ### Example
/// ```rust
/// // Bad
/// let x = 3.14;
/// // Good
/// let x = std::f32::consts::PI;
/// ```
#[clippy::version = "pre 1.29.0"]
pub APPROX_CONSTANT,
correctness,
"the approximate of a known float constant (in `std::fXX::consts`)"
}
```
dswij [Mon, 25 Oct 2021 04:29:05 +0000 (12:29 +0800)]
Check for no_std and no_core attribute in `swap` lint
This commit adds a `no_std` and `no_core` check on `swap` lint and additionally suggest `core::mem::swap` whenever possible.
Remove warning if both `std` and `core` is not present.
xFrednet [Thu, 21 Oct 2021 19:06:26 +0000 (21:06 +0200)]
Added `clippy::version` attribute to all normal lints
So, some context for this, well, more a story. I'm not used to scripting, I've never really scripted anything, even if it's a valuable skill. I just never really needed it. Now, `@flip1995` correctly suggested using a script for this in `rust-clippy#7813`...
And I decided to write a script using nushell because why not? This was a mistake... I spend way more time on this than I would like to admit. It has definitely been more than 4 hours. It shouldn't take that long, but me being new to scripting and nushell just wasn't a good mixture... Anyway, here is the script that creates another script which adds the versions. Fun...
Just execute this on the `gh-pages` branch and the resulting `replacer.sh` in `clippy_lints` and it should all work.
let paths = (open ./rust-1.58.0/lints.json | select id id_span | flatten | select id path);
let versions = (
ls | where name =~ "rust-" | select name | format {name}/lints.json |
each { open $it | select id | insert version $it | str substring "5,11" version} |
group-by id | rotate counter-clockwise id version |
update version {get version | first 1} | flatten | select id version);
$paths | each { |row|
let version = ($versions | where id == ($row.id) | format {version})
let idu = ($row.id | str upcase)
$"sed -i '0,/($idu),/{s/pub ($idu),/#[clippy::version = "($version)"]\n pub ($idu),/}' ($row.path)"
} | str collect ";" | str find-replace --all '1.00.0' 'pre 1.29.0' | save "replacer.sh";
```
And this still has some problems, but at this point I just want to be done -.-
Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.
Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts.
The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.
With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.
Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck).
cc `````@spastorino````` `````@lcnr`````
r? `````@nikomatsakis`````
bors [Tue, 9 Nov 2021 08:21:10 +0000 (08:21 +0000)]
Auto merge of #87337 - jyn514:lint-error, r=oli-obk,flip1995
Don't abort compilation after giving a lint error
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise
This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
Closes https://github.com/rust-lang/rust/issues/82761. This is a WIP because I have a feeling it will exit with 0 even if there were lint errors; I don't have a computer that can build rustc locally at the moment.
bors [Tue, 9 Nov 2021 05:33:16 +0000 (05:33 +0000)]
Auto merge of #90485 - camsteffen:fmt-args-less-bind, r=m-ou-se
Don't destructure args tuple in format_args!
This allows Clippy to parse the HIR more simply since `arg0` is changed to `_args.0`. (cc rust-lang/rust-clippy#7843). From rustc's perspective, I think this is something between a lateral move and a tiny improvement since there are fewer bindings.
Michael Wright [Tue, 9 Nov 2021 03:44:02 +0000 (05:44 +0200)]
Change `Bound` to `EndBound`
Only the end bounds of ranges can actually be included or excluded. This
commit changes the SpannedRange type to reflect that. Update `Kind::value`
to and `Kind::cmp` for this change. `Kind::cmp` gets flipped to check value
first and then the bound details and is much shorter.
Michael Wright [Tue, 9 Nov 2021 03:44:02 +0000 (05:44 +0200)]
Remove `unimplemented!()` case in matches code
This unbounded case never actually happens because `all_ranges(..)` uses
the scrutinee type bounds for open ranges. Switch to our own `Bound`
enum so that we don't have this case.