summary refs log tree commit diff
path: root/src/tools/clippy/clippy_lints
AgeCommit message (Collapse)AuthorLines
2020-11-12Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkovMara Bos-1/+10
Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern). Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes. r? ``@petrochenkov``
2020-11-12Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011bors-4/+4
Do not collect tokens for doc comments Doc comment is a single token and AST has all the information to re-create it precisely. Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736). (I also moved token collection into `fn parse_attribute` to deduplicate code a bit.) r? `@Aaron1011`
2020-11-11Implement destructuring assignment for structs and slicesFabian Zaiser-1/+10
Co-authored-by: varkor <github@varkor.com>
2020-11-11Fix typo in commentIkko Ashimine-1/+1
occurences -> occurrences
2020-11-09Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwcoDylan DPC-7/+1
rustc_ast: Do not panic by default when visiting macro calls Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them. The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
2020-11-09Do not collect tokens for doc commentsVadim Petrochenkov-4/+4
2020-11-05Merge commit 'b20d4c155d2fe3a8391f86dcf9a8c49e17188703' into clippyupflip1995-310/+1067
2020-11-04Auto merge of #78662 - sexxi-goose:add_expr_id_to_delegate, r=nikomatsakisbors-16/+16
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. Closes: https://github.com/rust-lang/project-rfc-2229/issues/20 r? `@ghost`
2020-11-04s/Scalar::Raw/Scalar::Intoli-1/+1
2020-11-04Split the "raw integer bytes" part out of `Scalar`Oliver Scherer-8/+9
2020-11-03rustc_ast: `visit_mac` -> `visit_mac_call`Vadim Petrochenkov-1/+1
2020-11-03rustc_ast: Do not panic by default when visiting macro callsVadim Petrochenkov-6/+0
2020-11-02Provide diagnostic suggestion in ExprUseVisitor DelegateDhruv Jauhar-16/+16
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. Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
2020-11-01Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelixbors-1/+1
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. cc `@pnkfelix`
2020-10-30Update Clippy path to `Lint`Aaron Hill-1/+1
2020-10-30Remove implicit `Continue` typeLeSeulArtichaut-1/+1
2020-10-30Use `ControlFlow::is{break,continue}`LeSeulArtichaut-2/+2
2020-10-30TypeVisitor: use `ControlFlow` in clippyLeSeulArtichaut-4/+6
2020-10-28Merge commit '645ef505da378b6f810b1567806d1bcc2856395f' into clippyupEduardo Broto-556/+1308
2020-10-26Remove lint from clippyNathan Whitaker-60/+0
2020-10-25Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkovYuki Okushi-2/+2
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. ```rust trait Foo { #[allow(unused_attributes)] #[inline] fn first(); #[inline] #[allow(unused_attributes)] fn second(); } ``` 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
2020-10-24Fix inconsistencies in handling of inert attributes on statementsAaron Hill-2/+2
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. ```rust trait Foo { #[allow(unused_attributes)] #[inline] fn first(); #[inline] #[allow(unused_attributes)] fn second(); } ``` 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
2020-10-23Remove duplicate import of `Target`Eduardo Broto-1/+0
2020-10-23Merge commit 'bf1c6f9871f430e284b17aa44059e0d0395e28a6' into clippyupEduardo Broto-343/+1000
2020-10-18Rollup merge of #77851 - exrook:split-btreemap, r=dtolnayYuki Okushi-1/+1
BTreeMap: refactor Entry out of map.rs into its own file btree/map.rs is approaching the 3000 line mark, splitting out the entry code buys about 500 lines of headroom. I've created this PR because the changes I've made in #77438 will push `map.rs` over the 3000 line limit and cause tidy to complain. I picked `Entry` to factor out because it feels less tightly coupled to the rest of `BTreeMap` than the various iterator implementations. Related: #60302
2020-10-17Appease the almightly lord clippy, hallowed be thy nameJacob Hughes-1/+1
2020-10-16Handle ExprKind::ConstBlock on clippySantiago Pastorino-1/+17
2020-10-15Remove rustc_session::config::Configest31-3/+3
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.
2020-10-10Refactor how SwitchInt stores jump targetsJonas Schievink-1/+0
2020-10-09Merge commit '2f6439ae6a6803d030cceb3ee14c9150e91b328b' into clippyupflip1995-342/+561
2020-10-06Fix toolsMatthew Jasper-8/+18
2020-10-06Rollup merge of #77560 - rschoon:fix-litkind-rc-bytebuf, r=lcnrYuki Okushi-1/+1
Fix LitKind's byte buffer to use refcounted slice While working on adding a new lint for clippy (see https://github.com/rust-lang/rust-clippy/pull/6044) for avoiding shared ownership of "mutable buffer" types (such as using `Rc<Vec<T>>` instead of `Rc<[T]>`), I noticed a type exported from rustc_ast and used by clippy gets caught by the lint. This PR fixes the exported type. This PR includes the actual change to clippy too, but I will open a PR directly against clippy for that part (although it will currently fail to build there).
2020-10-04clippy: `(Body, DefId)` -> `Body`Dylan MacKenzie-3/+4
2020-10-04Change clippy's Constant back to refcount clone byte stringsRobin Schoonover-1/+1
2020-10-02Deprecate clippy lintMichael Howell-79/+13
2020-09-26Remove all unstable feature support in the `missing_const_for_fn` lintOliver Scherer-97/+25
2020-09-26Move `qualify_min_const_fn` out of rustc into clippyOliver Scherer-1/+465
2020-09-25Auto merge of #77144 - flip1995:clippyup, r=Manishearthbors-297/+1286
Update Clippy Bi-weekly Clippy update. This includes a `Cargo.lock` update (d445493479711389f4dea3a0f433041077ba2088), so probably needs `rollup=never`. r? `@Manishearth`
2020-09-25Rollup merge of #76724 - ecstatic-morse:dataflow-pass-names, r=lcnrJonas Schievink-0/+1
Allow a unique name to be assigned to dataflow graphviz output Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
2020-09-24Merge commit 'e636b88aa180e8cab9e28802aac90adbc984234d' into clippyupflip1995-297/+1286
2020-09-21Remove `can_suggest` from Clippy.Christiaan Dirkx-62/+16
Removes `can_suggest` from as it is no longer used. Reverts rust-clippy#5724.
2020-09-20Auto merge of #76136 - CDirkx:const-result, r=dtolnaybors-4/+4
Stabilize some Result methods as const Stabilize the following methods of Result as const: - `is_ok` - `is_err` - `as_ref` A test is also included, analogous to the test for `const_option`. These methods are currently const under the unstable feature `const_result` (tracking issue: #67520). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations, see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135). Note: these methods are the only methods currently under the `const_result` feature, thus this PR results in the removal of the feature. Related: #76225
2020-09-20Update src/tools/clippy/clippy_lints/src/matches.rsCDirkx-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2020-09-20Remove `can_suggest` check for `is_ok` and `is_err`.Christiaan Dirkx-4/+4
`is_ok` and `is_err` are stabilized as const and can thus always be suggested.
2020-09-15Fix clippy hard-code slice::Iter pathLzu Tao-1/+1
2020-09-14Add pass names to some common dataflow analysesDylan MacKenzie-0/+1
2020-09-11Auto merge of #75800 - Aaron1011:feature/full-nt-tokens, r=petrochenkovbors-6/+6
Attach tokens to all AST types used in `Nonterminal` We perform token capturing when we have outer attributes (for nonterminals that support attributes - e.g. `Stmt`), or when we parse a `Nonterminal` for a `macro_rules!` argument. The full list of `Nonterminals` affected by this PR is: * `NtBlock` * `NtStmt` * `NtTy` * `NtMeta` * `NtPath` * `NtVis` * `NtLiteral` Of these nonterminals, only `NtStmt` and `NtLiteral` (which is actually just an `Expr`), support outer attributes - the rest only ever have token capturing perform when they match a `macro_rules!` argument. This makes progress towards solving https://github.com/rust-lang/rust/issues/43081 - we now collect tokens for everything that might need them. However, we still need to handle `#[cfg]`, inner attributes, and misc pretty-printing issues (e.g. #75734) I've separated the changes into (mostly) independent commits, which could be split into individual PRs for each `Nonterminal` variant. The purpose of having them all in one PR is to do a single Crater run for all of them. Most of the changes in this PR are trivial (adding `tokens: None` everywhere we construct the various AST structs). The significant changes are: * `ast::Visibility` is changed from `type Visibility = Spanned<VisibilityKind>` to a `struct Visibility { kind, span, tokens }`. * `maybe_collect_tokens` is made generic, and used for both `ast::Expr` and `ast::Stmt`. * Some of the statement-parsing functions are refactored so that we can capture the trailing semicolon. * `Nonterminal` and `Expr` both grew by 8 bytes, as some of the structs which are stored inline (rather than behind a `P`) now have an `Option<TokenStream>` field. Hopefully the performance impact of doing this is negligible.
2020-09-10Fully integrate token collection for additional AST structsAaron Hill-6/+6
This commit contains miscellaneous changes that don't fit into any of the other commits in this PR
2020-09-10Merge commit '5034d47f721ff4c3a3ff2aca9ef2ef3e1d067f9f' into clippyupflip1995-184/+434
2020-09-10Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obkbors-3/+1
Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..`, this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`), including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary, the original `const` item will not be modified.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-08 22:15:01 +0000