bors [Sun, 25 Oct 2020 17:35:33 +0000 (17:35 +0000)]
Auto merge of #6202 - giraffate:fix_invalid_suggestion_in_needless_collect_test, r=flip1995
Fix an invalid suggestion in `needless_collect` test
A test, https://github.com/rust-lang/rust-clippy/blob/master/tests/ui/needless_collect_indirect.rs#L11-L12, suggests following codes, but the suggested codes don't work. An example is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6947d9f2806a83f41cc5eb8e39b09d0b.
```
error: avoid using `collect()` when not needed
--> $DIR/needless_collect_indirect.rs:11:5
|
LL | / let indirect_contains = sample.iter().collect::<VecDeque<_>>();
LL | | indirect_contains.contains(&&5);
| |____^
|
help: Check if the original Iterator contains an element instead of collecting then checking
|
LL |
LL | sample.iter().any(|x| x == &&5);
```
bors [Sun, 25 Oct 2020 11:58:51 +0000 (11:58 +0000)]
Auto merge of #6222 - JohnTitor:redundant-local-def-id, r=flip1995
Remove redundant `expect_local()` call
The field `owner` of `HirId` is `LocalDefId` and `hir_id.owner.to_def_id().expect_local()` is redundant. I wonder they were introduced in some rustups.
bors [Sun, 25 Oct 2020 09:56:16 +0000 (09:56 +0000)]
Auto merge of #6162 - josephlr:empty-loop-no-std, r=flip1995
Update empty_loop documentation/message.
Originally part of #6161, but now this PR only deals with `std` crates
This change:
- Updates the `std` message .
- Updates the docs to mention how the busy loops should be fixed
- Gives examples of how to do this for `no_std` targets
- Updates the tests/stderr files to test this change.
Yuki Okushi [Sun, 25 Oct 2020 09:43:49 +0000 (18:43 +0900)]
Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov
Split out statement attributes changes from #78306
This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).
This shouldn't have any user-visible effects, so it can be landed without lang team discussion.
---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
bors [Sun, 25 Oct 2020 09:37:09 +0000 (09:37 +0000)]
Auto merge of #6181 - cgm616:undropped-manually-drops, r=flip1995
Add new lint for undropped ManuallyDrop values
Adds a new lint for the following code:
```rust
struct S;
impl Drop for S {
fn drop(&mut self) {
println!("drip drop");
}
}
fn main() {
// This will not drop the `S`!!!
drop(std::mem::ManuallyDrop::new(S));
unsafe {
// This will.
std::mem::ManuallyDrop::drop(&mut std::mem::ManuallyDrop::new(S));
}
}
```
The inner value of a `ManuallyDrop` will not be dropped unless the proper, unsafe drop function is called on it. This lint makes sure that a user does not accidently use the wrong function and forget to drop a `ManuallyDrop` value.
bors [Sun, 25 Oct 2020 08:54:27 +0000 (08:54 +0000)]
Auto merge of #6029 - Daniel-B-Smith:refcell_ref_await, r=flip1995
Add lint for holding RefCell Ref across an await
Fixes #6008
This introduces the lint await_holding_refcell_ref. For async functions, we iterate
over all types in generator_interior_types and look for `core::cell::Ref` or `core::cell::RefMut`. If we find one then we emit a lint.
bors [Sat, 24 Oct 2020 23:29:49 +0000 (23:29 +0000)]
Auto merge of #6187 - geoffreycopin:master, r=ebroto
Lint unnecessary int-to-int and float-to-float casts
This is an implementation of a lint that detects unnecessary casts of number literals, as discussed here:
https://github.com/rust-lang/rust-clippy/issues/6116
---
changelog: lint unnecessary as-casts of literals when they could be written using literal syntax.
bors [Sat, 24 Oct 2020 22:31:53 +0000 (22:31 +0000)]
Auto merge of #6135 - cauebs:master, r=ebroto
Add large_types_passed_by_value lint
Creates a new lint that checks for large function parameters passed by value. ~Types that are Copy were ignored, because I understand they are explicitly marked as being cheap (or just acceptable) to copy. Arrays were excluded from that restriction because they are always Copy, independently of the size, if the elements are Copy.~ Only Copy types are considered, because if a type is not Copy it cannot be dereferenced, as pointed out by `@ebroto,` and that would require analyzing the whole function body to check if the argument is moved somewhere else. `self` and `mut` parameters are also skipped.
I refactored `trivially_copy_pass_by_ref` and the new lint into a new `pass_by_ref_or_value` module, since both share most of their implementations, as was pointed out to me in #4499.
~Some questions that remain:~
~1. Should `self` be disregarded for this lint?~
~2. Should we special case types like Vec and String when suggesting changes? (to slices and &str)~
~3. What should be the default size limit?~
~4. Are there any special cases I'm missing?~
I ask the maintainers to add the `hacktoberfest-accepted` label if this PR is decent, even if there are some minor details to work out, but I do intend to stick around and finish the job.
Fixes #4499
changelog: Add new lint [`large_types_passed_by_value`]
Aaron Hill [Fri, 23 Oct 2020 22:17:00 +0000 (18:17 -0400)]
Fix inconsistencies in handling of inert attributes on statements
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
bors [Tue, 20 Oct 2020 09:38:38 +0000 (09:38 +0000)]
Auto merge of #6193 - Ryan1729:add-more-LintStore-documentation, r=phansch
Add more infomation about LintStore registration
Backstory: I somehow missed the fact that I needed to register a lint pass in order for it to run, and I spent some time confused until I figured it out. So I wanted to make it clear that a missing `register_(early|late)_pass` call is a likely cause of a lint not running.
bors [Mon, 19 Oct 2020 13:17:07 +0000 (13:17 +0000)]
Auto merge of #6166 - achris:master, r=flip1995
Suggest a compatible shell for setup-toolchain.sh
setup-toolchain.sh uses "[[" which is a bash builtin, but the guide
suggests running it with sh. On Ubuntu, /bin/sh points to dash and
running the script fails.
Ryan Wiedemann [Sun, 18 Oct 2020 23:01:57 +0000 (17:01 -0600)]
Add more infomation about LintStore registration
Backstory: I somehow missed the fact that I needed to register a lint pass in order for it to run, and I spent some time confused until I figured it out. So I wanted to make it clear that a missing `register_(early|late)_pass` call is a likely cause of a lint not running.
bors [Fri, 16 Oct 2020 07:45:42 +0000 (07:45 +0000)]
Auto merge of #6178 - josephlr:sync-from-rust, r=phansch
Sync from rust
Fix rustc breakage by running:
```rust
git subtree push -P src/tools/clippy git@github.com:josephlr/rust-clippy sync-from-rust
```
and then adding a commit that runs `cargo dev fmt`
est31 [Wed, 14 Oct 2020 16:42:13 +0000 (18:42 +0200)]
Remove rustc_session::config::Config
The wrapper type led to tons of target.target
across the compiler. Its ptr_width field isn't
required any more, as target_pointer_width
is already present in parsed form.
it took me a while to figure out why `cargo clippy -- -Aclippy::pedantic -Wclippy::items-after-statements` still showed me *all* the lints. At first I thought it was due to the missing spaces in the current example and I debugged that until I stumbled across an issue noting that you have to touch a random file or run `cargo clean` when you're running clippy repeatedly on an unchanged codebase. This PR is an attempt to save the next person some time and also structure the "Allowing/denying lints" section a bit more while we're at it.
projects / rust.git / log