about summary refs log tree commit diff
path: root/src/tools/clippy
AgeCommit message (Collapse)AuthorLines
2024-07-04fix tests after rebaseBennet Bleßmann-2/+2
2024-07-04Rollup merge of #127301 - estebank:fix-suggestions, r=UrgauMatthias Krüger-15/+0
Tweak some structured suggestions to be more verbose and accurate Addressing some issues I found while working on #127282. ``` error: this URL is not a hyperlink --> $DIR/auxiliary/include-str-bare-urls.md:1:11 | LL | HEADS UP! https://example.com MUST SHOW UP IN THE STDERR FILE! | ^^^^^^^^^^^^^^^^^^^ | = note: bare URLs are not automatically turned into clickable links note: the lint level is defined here --> $DIR/include-str-bare-urls.rs:14:9 | LL | #![deny(rustdoc::bare_urls)] | ^^^^^^^^^^^^^^^^^^ help: use an automatic link instead | LL | HEADS UP! <https://example.com> MUST SHOW UP IN THE STDERR FILE! | + + ``` ``` error[E0384]: cannot assign twice to immutable variable `v` --> $DIR/assign-imm-local-twice.rs:7:5 | LL | v = 1; | ----- first assignment to `v` LL | println!("v={}", v); LL | v = 2; | ^^^^^ cannot assign twice to immutable variable | help: consider making this binding mutable | LL | let mut v: isize; | +++ ``` ``` error[E0393]: the type parameter `Rhs` must be explicitly specified --> $DIR/issue-22560.rs:9:23 | LL | trait Sub<Rhs=Self> { | ------------------- type parameter `Rhs` must be specified for this ... LL | type Test = dyn Add + Sub; | ^^^ | = note: because of the default `Self` reference, type parameters must be specified on object types help: set the type parameter to the desired type | LL | type Test = dyn Add + Sub<Rhs>; | +++++ ``` ``` error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable --> $DIR/issue-33819.rs:4:34 | LL | Some(ref v) => { let a = &mut v; }, | ^^^^^^ cannot borrow as mutable | help: try removing `&mut` here | LL - Some(ref v) => { let a = &mut v; }, LL + Some(ref v) => { let a = v; }, | ``` ``` help: remove the invocation before committing it to a version control system | LL - dbg!(); | ``` ``` error[E0308]: mismatched types --> $DIR/issue-39974.rs:1:21 | LL | const LENGTH: f64 = 2; | ^ expected `f64`, found integer | help: use a float literal | LL | const LENGTH: f64 = 2.0; | ++ ``` ``` error[E0529]: expected an array or slice, found `Vec<i32>` --> $DIR/match-ergonomics.rs:8:9 | LL | [&v] => {}, | ^^^^ pattern cannot match with input type `Vec<i32>` | help: consider slicing here | LL | match x[..] { | ++++ ``` ``` error[E0609]: no field `0` on type `[u32; 1]` --> $DIR/parenthesized-deref-suggestion.rs:10:21 | LL | (x as [u32; 1]).0; | ^ unknown field | help: instead of using tuple indexing, use array indexing | LL | (x as [u32; 1])[0]; | ~ + ```
2024-07-04Properly handle removal suggestion renderingEsteban Küber-15/+0
Do not leave a `+ ` line with only whitespace. In reality, the user will want to remove the entire line.
2024-07-04Auto merge of #127127 - notriddle:notriddle/pulldown-cmark-0.11, ↵bors-16/+16
r=GuillaumeGomez rustdoc: update to pulldown-cmark 0.11 r? rustdoc This pull request updates rustdoc to the latest version of pulldown-cmark. Along with adding new markdown extensions (which this PR doesn't enable), the new pulldown-cmark version also fixes a large number of bugs. Because all text files successfully parse as markdown, these bugfixes change the output, which can break people's existing docs. A crater run, https://github.com/rust-lang/rust/pull/121659, has already been run for this change. The first commit upgrades and fixes rustdoc. The second commit adds a lint for the footnote and block quote parser changes, which break the largest numbers of docs in the Crater run. The strikethrough change was mitigated in pulldown-cmark itself. Unblocks https://github.com/rust-lang/rust-clippy/pull/12876
2024-07-03Auto merge of #125507 - compiler-errors:type-length-limit, r=lcnrbors-3/+3
Re-implement a type-size based limit r? lcnr This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in #72412, which caused the `walk` function to no longer walk over identical elements. Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode). This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired. Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future. Fixes #125460
2024-07-02Instance::resolve -> Instance::try_resolve, and other nitsMichael Goulet-3/+3
2024-07-02chore: remove duplicate wordshattizai-3/+3
2024-07-01clippy: update to pulldown-cmark 0.11Michael Howell-16/+16
2024-06-29Auto merge of #120639 - fee1-dead-contrib:new-effects-desugaring, r=oli-obkbors-8/+25
Implement new effects desugaring cc `@rust-lang/project-const-traits.` Will write down notes once I have finished. * [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>` * [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>` * [ ] add types and traits to minicore test * [ ] update rustc-dev-guide Fixes #119717 Fixes #123664 Fixes #124857 Fixes #126148
2024-06-29Rollup merge of #127045 - compiler-errors:explicit, r=oli-obkMatthias Krüger-3/+3
Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated Rename: * `super_predicates_of` -> `explicit_super_predicates_of` * `implied_predicates_of` -> `explicit_implied_predicates_of` * `supertraits_containing_assoc_item` -> `explicit_supertraits_containing_assoc_item` This makes it clearer that, unlike (for example) [`TyCtxt::super_traits_of`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.super_traits_of), we don't automatically elaborate this set of predicates. r? ``@lcnr`` or ``@oli-obk`` or someone from t-types idc
2024-06-28address review commentsDeadbeef-1/+9
2024-06-28finishing touches, move fixed ICEs to ui testsDeadbeef-7/+16
2024-06-28Rollup merge of #127058 - compiler-errors:tighten-async-spans, r=oli-obkMatthias Krüger-2/+2
Tighten `fn_decl_span` for async blocks Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way. I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters. r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
2024-06-27Tighten spans for async blocksMichael Goulet-2/+2
2024-06-27Merge commit '68a799aea9b65e2444fbecfe32217ce7d5a3604f' into ↵Philipp Krones-1008/+3631
clippy-subtree-update
2024-06-27Make queries more explicitMichael Goulet-3/+3
2024-06-26Auto merge of #120924 - xFrednet:rfc-2383-stabilization-party, r=Urgau,blyxyasbors-573/+602
Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) Let's give this another try! The [previous stabilization attempt](https://github.com/rust-lang/rust/pull/99063) was stalled by some unresolved questions. These have been discussed in a [lang team](https://github.com/rust-lang/lang-team/issues/191) meeting. The last open question, regarding the semantics of the `#[expect]` attribute was decided on in https://github.com/rust-lang/rust/issues/115980 I've just updated the [stabilization report](https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964) with the discussed questions and decisions. Luckily, the decision is inline with the current implementation. This hopefully covers everything. Let's hope that the CI will be green like the spring. fixes #115980 fixes #54503 --- r? `@wesleywiser` Tacking Issue: https://github.com/rust-lang/rust/issues/54503 Stabilization Report: https://github.com/rust-lang/rust/issues/54503#issuecomment-1179563964 Documentation Update: https://github.com/rust-lang/reference/pull/1237 <!-- For Clippy: changelog: [`allow_attributes`]: Is now available on stable, since the `lint_reasons` feature was stabilized changelog: [`allow_attributes_without_reason`]: Is now available on stable, since the `lint_reasons` feature was stabilized --> --- Roses are red, Violets are blue, Let's expect lints, With reason clues
2024-06-25`sudo CI=green` && Review changes <3xFrednet-11/+2
2024-06-25Rollup merge of #126893 - dtolnay:prec, r=compiler-errorsMatthias Krüger-5/+5
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer). As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals). There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast/src/util/parser.rs#L236-L237 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L2829 https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L1290 In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1. There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax &mdash; you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level. https://github.com/rust-lang/rust/blob/d49994b060684af423339b55769439b2f444a7b9/compiler/rustc_ast_pretty/src/pprust/state/expr.rs#L217-L221
2024-06-25RFC 2383: Stabilize `lint_reasons` in Clippy :paperclips:xFrednet-573/+611
2024-06-25Auto merge of #125741 - petrochenkov:atvisord, r=davidtwcobors-61/+61
ast: Standardize visiting order for attributes and node IDs This should only affect `macro_rules` scopes and order of diagnostics. Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
2024-06-24Replace Deref bounds on Interner in favor of a SliceLike traitMichael Goulet-1/+1
2024-06-24Split out IntoIterator and non-Iterator constructors for ↵Michael Goulet-8/+8
AliasTy/AliasTerm/TraitRef/projection
2024-06-24ast: Standardize visiting order for attributes and node IDsVadim Petrochenkov-61/+61
2024-06-23Rename the 2 unambiguous precedence levels to PREC_UNAMBIGUOUSDavid Tolnay-5/+5
2024-06-22Rollup merge of #126723 - estebank:dot-dot-dot, r=NadrierilGuillaume Gomez-4/+4
Fix `...` in multline code-skips in suggestions When we have long code skips, we write `...` in the line number gutter. For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
2024-06-20StaticForeignItem and StaticItem are the sameMichael Goulet-2/+2
2024-06-20Fix `...` in multline code-skips in suggestionsEsteban Küber-4/+4
When we have long code skips, we write `...` in the line number gutter. For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
2024-06-19Update float tests to include `f16` and `f128`Trevor Gross-522/+792
2024-06-19Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`sTrevor Gross-10/+52
This removes the ICE codepaths for `f16` and `f128` in Clippy. `rustc_apfloat` is used as a dependency for the parsing of these types, since their `FromStr` implementation will not be available in the standard library for a while.
2024-06-18Use a dedicated type instead of a reference for the diagnostic contextOli Scherer-2/+2
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
2024-06-17Fix other toolsMichael Goulet-4/+1
2024-06-17Rework precise capturing syntaxMichael Goulet-1/+1
2024-06-13Tweak output of import suggestionsEsteban Küber-3/+1
When both `std::` and `core::` items are available, only suggest the `std::` ones. We ensure that in `no_std` crates we suggest `core::` items. Ensure that the list of items suggested to be imported are always in the order of local crate items, `std`/`core` items and finally foreign crate items. Tweak wording of import suggestion: if there are multiple items but they are all of the same kind, we use the kind name and not the generic "items". Fix #83564.
2024-06-13Auto merge of #126398 - flip1995:clippy-subtree-update, r=Manishearthbors-1667/+3098
Clippy subtree update r? `@Manishearth` Updates `Cargo.lock` with Clippy version bump.
2024-06-13Merge commit '3e5a02b13b1244545454752c6629b767522a44b1' into ↵Philipp Krones-1667/+3098
clippy-subtree-update
2024-06-13Fixup clippy testsWaffle Lapkin-6/+2
Don't depend on the fact that `!` falls back to `()` and so panic-ish things can be used in `-> impl ImplementedForUnit` functions
2024-06-10Rollup merge of #126159 - RalfJung:scalarint-size-mismatch, r=oli-obkMatthias Krüger-24/+9
ScalarInt: size mismatches are a bug, do not delay the panic Cc [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Why.20are.20ScalarInt.20to.20iN.2FuN.20methods.20fallible.3F) r? ``@oli-obk``
2024-06-10ScalarInt: size mismatches are a bug, do not delay the panicRalf Jung-24/+9
2024-06-09Update `icu4x` dependenciesclubby789-1/+1
2024-06-08Rollup merge of #125951 - slanterns:error_in_core_stabilization, r=AmanieuLeón Orell Valerian Liehr-4/+10
Stabilize `error_in_core` Closes: https://github.com/rust-lang/rust/issues/103765. `@rustbot` label: +T-libs-api r? libs-api
2024-06-07Auto merge of #125918 - oli-obk:const_block_ice, r=compiler-errorsbors-34/+10
Revert: create const block bodies in typeck via query feeding as per the discussion in https://github.com/rust-lang/rust/pull/125806#discussion_r1622563948 It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile. reverts the const-block-specific parts of https://github.com/rust-lang/rust/pull/124650 `@bors` rollup=never had a small perf impact previously fixes https://github.com/rust-lang/rust/issues/125846 r? `@compiler-errors`
2024-06-07Revert "Create const block DefIds in typeck instead of ast lowering"Oli Scherer-34/+10
This reverts commit ddc5f9b6c1f21da5d4596bf7980185a00984ac42.
2024-06-06Rollup merge of #126101 - lqd:revert-124099, r=wesleywiserJubilee-6/+6
Revert "Disallow ambiguous attributes on expressions" on nightly As discussed in [today's t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-06/near/443079505), this reverts PR #124099 to fix P-critical beta regressions #125199. r? ``@wesleywiser`` Opening as draft so that ``@wesleywiser`` and ``@apiraino,`` you can tell me whether you wanted: 1. a `beta-accepted` revert of #124099 on nightly (this PR)? That will need to be backported to beta (even though #126093 may be the last of those) 2. a revert of #124099 on beta? 3. all of the above? I also opened #126102, another draft PR to revert #124099 on beta, should you choose options 2 or 3.
2024-06-07bless `std_instead_of_core`Slanterns-4/+10
2024-06-06Revert "Rollup merge of #124099 - voidc:disallow-ambiguous-expr-attrs, ↵Rémy Rakic-6/+6
r=davidtwco" This reverts commit 57dad1d75e562ff73051c1c43b07eaf65c7dbd74, reversing changes made to 36316df9fe6c3e246153fe6e78967643cf08c148.
2024-06-06Auto merge of #126068 - lqd:revert-124976, r=petrochenkovbors-1/+1
Revert "use `tcx.used_crates(())` more" before it reaches beta There are more open issues caused by #124976 than will be fixed by #125493 alone. The beta cut is soon, so let's revert it and buy some time to analyze and fix these issues in our own time. fixes https://github.com/rust-lang/rust/issues/125474 fixes https://github.com/rust-lang/rust/issues/125484 fixes https://github.com/rust-lang/rust/issues/125646 fixes https://github.com/rust-lang/rust/issues/125707 fixes #126066 fixes #125934 fixes https://github.com/rust-lang/rust/issues/126021 r? `@petrochenkov` `@bors` p=1
2024-06-06Revert "Rollup merge of #124976 - petrochenkov:usedcrates, r=oli-obk"Rémy Rakic-1/+1
This reverts commit eda4a35f365535af72118118a3597edf5a13c12d, reversing changes made to eb6b35b5bcb3c2a594cb29cd478aeb2893f49d30.
2024-06-06Auto merge of #124482 - spastorino:unsafe-extern-blocks, r=oli-obkbors-2/+6
Unsafe extern blocks This implements RFC 3484. Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484 This is better reviewed commit by commit.
2024-06-05Misc fixes to cranelift/clippy/miriBoxy-7/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 11:37:32 +0000