bors [Sun, 8 Nov 2020 11:41:22 +0000 (11:41 +0000)]
Auto merge of #6205 - josephlr:empty-loop2, r=flip1995
Enable empty_loop lint for no_std crates
Depends on #6162. Fixes #6161
We skip the lint if the `loop {}` is in the `#[panic_handler]` as the
main recommendation we give is to panic, which obviously isn't
possible in a panic handler.
changelog: Enable empty_loop lint for no_std crates
Joe Richey [Fri, 23 Oct 2020 06:39:25 +0000 (23:39 -0700)]
Enable empty_loop lint for no_std crates
We skip the lint if the `loop {}` is in the `#[panic_handler]` as the
main recommendation we give is to panic, which obviously isn't
possible in a panic handler.
bors [Sat, 7 Nov 2020 15:51:13 +0000 (15:51 +0000)]
Auto merge of #6110 - rail-rain:care_enums_non_copy_const, r=llogiq
"Respect" enums in `interior_mutable_const`
fixes #3962
fixes #3825
Hello,
It might not be a good idea to submit another relatively large PR while I have an opened PR; but, I've finished this anyway. This may be able to wait for months.
Note: the code uses the MIR interpreter, which the author of #3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (#3825). (And, I don't want to write a MIR visitor)
---
changelog: fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted
even if it uses a clearly unfrozen variant
bors [Wed, 4 Nov 2020 22:45:15 +0000 (22:45 +0000)]
Auto merge of #78662 - sexxi-goose:add_expr_id_to_delegate, r=nikomatsakis
Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate trait](https://github.com/rust-lang/rust/blob/981346fc07dd5ef414c5b1b21999f7604cece006/compiler/rustc_typeck/src/expr_use_visitor.rs#L28-L38) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
bors [Wed, 4 Nov 2020 22:21:44 +0000 (22:21 +0000)]
Auto merge of #5911 - hegza:issue-568, r=ebroto
Add lint for 'field_reassign_with_default` #568
changelog: Add lint for field_reassign_with_default that checks if mutable object + field modification is used to edit a binding initialized with Default::default() instead of struct constructor.
Fixes #568
Notes:
- Checks for reassignment of one or more fields of a binding initialized with Default::default().
- Implemented using EarlyLintPass, might be future proofed better with LateLintPass.
- Does not trigger if Default::default() is used via another type implementing Default.
- This is a re-open of [PR#4761](https://github.com/rust-lang/rust-clippy/pull/4761), but I couldn't figure out how to re-open that one so here's a new one with the requested changes :S
bors [Wed, 4 Nov 2020 09:22:54 +0000 (09:22 +0000)]
Auto merge of #6284 - camsteffen:rustc-sym, r=flip1995
Use const sym where possible
I ran a regex search and replace to use const `sym` values where possible. This should give some performance boost by avoiding string interning at runtime.
Con: It is not as consistent as always using `sym!`.
I also changed an internal lint to suggest using `sym::{}`, making an assumption that this will always work for diagnostic items.
Disable and enable when not specifically explained were not clear to me
as an English language speaker, but I was able to figure it out fairly
easily due to the examples having A/W, which I assumed meant `allow` and
`warn`. I removed both words to be sure it was clear as well as
extending the note on what deny means. It now includes a statement on
exactly what each word means.
bors [Tue, 3 Nov 2020 16:21:51 +0000 (16:21 +0000)]
Auto merge of #6165 - dvermd:ref_option_ref, r=flip1995
Add lint 'ref_option_ref' #1377
This lint checks for usage of `&Option<&T>` which can be simplified as `Option<&T>` as suggested in #1377.
This WIP PR is here to get feedback on the lint as there's more cases to be handled:
* statics/consts,
* associated types,
* type alias,
* function/method parameter/return,
* ADT definitions (struct/tuple struct fields, enum variants)
bors [Tue, 3 Nov 2020 15:59:16 +0000 (15:59 +0000)]
Auto merge of #6101 - pitiK3U:from_iter_instead_of_collect, r=flip1995
Add lint: from_iter_instead_of_collect
Fixes #5679
This implements lint for `::from_iter()` from #5679 not the general issue (`std::ops::Add::add`, etc.).
This lint checks if expression is function call with `from_iter` name and if it's implementation of the `std::iter::FromIterator` trait.
Dhruv Jauhar [Sun, 1 Nov 2020 07:15:22 +0000 (02:15 -0500)]
Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate
trait](https://github.com/rust-lang/rust/blob/981346fc07dd5ef414c5b1b21999f7604cece006/compiler/rustc_typeck/src/expr_use_visitor.rs#L28-L38)
currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
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.
Henri Lunnikivi [Thu, 31 Oct 2019 16:02:02 +0000 (18:02 +0200)]
Implement field_reassign_with_default
- Implement `field_reassign_with_default` as a `LateLintPass`
- Avoid triggering `default_trait_access` on a span already linted by
`field_reassigned_with_default`
- Merge `default_trait_access` and `field_reassign_with_default` into
`Default`
- Co-authored-by: Eduardo Broto <ebroto@tutanota.com>
- Fixes #568
Randall Mason [Fri, 30 Oct 2020 17:16:11 +0000 (12:16 -0500)]
Clarify allow/warn/deny. Remove enable/disable.
Disable and enable when not specifically explained were not clear to me
as an English language speaker, but I was able to figure it out fairly
easily due to the examples having A/W, which I assumed meant `allow` and
`warn`. I removed both words to be sure it was clear as well as
extending the note on what deny means. It now includes a statement on
exactly what each word means.
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
projects / rust.git / log