about summary refs log tree commit diff
path: root/src/tools/clippy
AgeCommit message (Collapse)AuthorLines
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-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-672/+2832
2020-10-26Remove lint from clippyNathan Whitaker-140/+3
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-566/+2120
2020-10-22Fix clippy testsvarkor-0/+3
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-16Rollup merge of #77493 - ↵Dylan DPC-3/+5
hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk ICEs should always print the top of the query stack see #76920
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-14fix stderr file of clippy/custom_ice_message testhosseind88-1/+1
2020-10-13Auto merge of #77796 - jonas-schievink:switchint-refactor, r=oli-obkbors-1/+0
Refactor how SwitchInt stores jump targets Closes https://github.com/rust-lang/rust/issues/65693
2020-10-11Auto merge of #77649 - dash2507:replace_run_compiler, r=matthewjasperbors-2/+2
Replace run_compiler with RunCompiler builder pattern Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.
2020-10-10Refactor how SwitchInt stores jump targetsJonas Schievink-1/+0
2020-10-09rebase with masterhosseind75-1/+3
2020-10-09add new linehosseind75-1/+1
2020-10-09fix clippy custom_ice_message testhosseind75-0/+2
2020-10-09run full query stack print just when RUST_BACKTRACE is sethosseind75-1/+4
2020-10-09ICEs should print the top of the query stackhosseind75-6/+1
2020-10-09Merge commit '2f6439ae6a6803d030cceb3ee14c9150e91b328b' into clippyupflip1995-616/+1502
2020-10-08Replace run_compiler with RunCompiler builder pattern.Darshan Kathiriya-2/+2
RunCompiler::new takes non-optional params, and optional params can be set using set_*field_name* method. finally `run` will forward all fields to `run_compiler`.
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-06Rollup merge of #77534 - ↵Yuki Okushi-13/+4
Mark-Simulacrum:issue-70819-disallow-override-forbid-in-same-scope, r=petrochenkov Disallow overriding forbid in same scope Rebased #73379. Fixes #70819.
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-04Prevent forbid from being ignored if overriden at the same level.Felix S. Klock II-13/+4
That is, this changes `#[forbid(foo)] #[allow(foo)]` from allowing foo to forbidding foo.
2020-10-02Deprecate clippy lintMichael Howell-111/+21
2020-09-28Rollup merge of #76474 - bjorn3:driver_selected_codegen, r=oli-obkRalf Jung-2/+2
Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri)
2020-09-27Add option to pass a custom codegen backend from a driverbjorn3-2/+2
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-965/+3418
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-965/+3418
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-20Update Clippy testcasesChristiaan Dirkx-65/+91
Update the test `redundant_pattern_matching`: check if `is_some` and `is_none` are suggested within const contexts.
2020-09-20Auto merge of #76136 - CDirkx:const-result, r=dtolnaybors-187/+97
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-20Update Clippy testcasesChristiaan Dirkx-183/+93
Update the test `redundant_pattern_matching`: check if `is_ok` and `is_err` are suggested within const contexts. Also removes the `redundant_pattern_matching_const_result` test, as it is no longer needed.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 09:07:36 +0000