bors [Sun, 1 Nov 2020 16:52:28 +0000 (16:52 +0000)]
Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix
Implement rustc side of report-future-incompat
cc https://github.com/rust-lang/rust/issues/71249
This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).
My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.
Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.
Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.
I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.
bors [Fri, 30 Oct 2020 12:37:46 +0000 (12:37 +0000)]
Auto merge of #6229 - henil:improve-integer-division-lint, r=phansch
Update the existing arithmetic lint
re: #6209
Updates the lint to not the error message if RHS of binary operation `/` of `%` is a literal/constant that is not `0` or `-1`, as suggested [here](https://github.com/rust-lang/rust-clippy/issues/6209#issuecomment-715624354)
changelog: Expand [`integer_arithmetic`] to work with RHS literals and constants
bors [Thu, 29 Oct 2020 15:12:24 +0000 (15:12 +0000)]
Auto merge of #6226 - Urcra:master, r=flip1995
Add lint for comparing to empty slices instead of using .is_empty()
Hey first time making a clippy lint
I added the implementation of the lint the `len_zero` since it shared a lot of the code, I would otherwise have to rewrite. Just tell me if the lint should use it's own file instead
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.
projects / rust.git / log