Clippy subtree update #127049
Merged
Clippy subtree update #127049
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…isual column space. Force filter wrapping with flex for small screens.
Co-authored-by: Fridtjof Stoldt <xFrednet@gmail.com>
Don't depend on the fact that `!` falls back to `()` and so panic-ish things can be used in `-> impl ImplementedForUnit` functions
…nishearth Clippy subtree update r? `@Manishearth` Updates `Cargo.lock` with Clippy version bump.
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 rust-lang#83564.
Fix doc nits Clippy is wonderful, and reading its lints is a great way to learn about Rust. While doing this, I noticed a few little copyedits, such as adding trailing periods to sentences, or tweaking wording very slightly to improve its readability. I hope you will accept these suggestions as an act of love for the project, with my thanks for all the maintainers' hard work. changelog: Docs [ mut_range_bound ]: fix doc nits changelog: Docs [ needless_for_each ]: fix doc nits changelog: Docs [ arc_with_non_send_sync ]: fix doc nits changelog: Docs [ allow_attributes ]: fix doc nits changelog: Docs [ allow_attributes_without_reason ]: fix doc nits
…xendoo Avoid emitting `assigning_clones` when cloned data borrows from the place to clone into Fixes rust-lang#12444 Fixes rust-lang#12460 Fixes rust-lang#12749 Fixes rust-lang#12757 Fixes rust-lang#12929 I think the documentation for the function should describe what- and how this is fixing the issues well. It avoids emitting a warning when the data being cloned borrows from the place to clone into, which is information that we can get from `PossibleBorrowerMap`. Unfortunately, it is a tiny bit tedious to match on the MIR like that and I'm not sure if this is possibly relying a bit too much on the exact MIR lowering for assignments. Things left to do: - [x] Handle place projections (or verify that they work as expected) - [x] Handle non-`Drop` types changelog: [`assigning_clones`]: avoid warning when the suggestion would lead to a borrow-check error
…r_comparison, r=Alexendoo Add MSRV for manual_pattern_char_comparison Fixes rust-lang#12936 changelog: [`manual_pattern_char_comparison`]: Add MSRV 1.58
Run a diff of lintcheck against the merge base for pull requests changelog: none <!-- changelog_checked --> This is an MVP of sorts, it consists of rust-lang#9764 + a GitHub action that feeds the output to the [job summary](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary). It doesn't yet do anything fancy like `--recursive` or adding comments to the PR, so you'd have to click through to the action to see the results Example output of a change (Alexendoo/rust-clippy@0be1ab8): https://github.com/Alexendoo/rust-clippy/actions/runs/4264858870#summary-11583333018 r? `@flip1995`
…=xFrednet Merge lintcheck popular-crates bin as a subcommand Also rewrites it to use `ureq` to drop some heavy dependencies as `crates_io_api` brings in `reqwest` r? `@xFrednet` changelog: none
…1995 Cache lintcheck binary in ci Always trims ~40s off the `diff` job as it no longer needs to install the rust toolchain or compile lintcheck. Saves a further ~20s for the `base`/`head` jobs when the cache is warm It now uses artifacts for restoring the JSON between jobs as per rust-lang/rust-clippy#10398 (comment), cc `@flip1995` The lintcheck changes are to make `./target/debug/lintcheck` work, running `cargo-clippy`/`clippy-driver` directly doesn't work without `LD_LIBRARY_PATH`/etc being set which is currently being done by `cargo run`. By merging the `--recursive` and normal cases to both go via regular `cargo check` we can have Cargo set up the environment for us r? `@xFrednet` changelog: none
…sTerm/TraitRef/projection
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 rust-lang#124535.
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 — 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
…y, r=Urgau,blyxyas Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) Let's give this another try! The [previous stabilization attempt](rust-lang#99063) was stalled by some unresolved questions. These have been discussed in a [lang team](rust-lang/lang-team#191) meeting. The last open question, regarding the semantics of the `#[expect]` attribute was decided on in rust-lang#115980 I've just updated the [stabilization report](rust-lang#54503 (comment)) 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 rust-lang#115980 fixes rust-lang#54503 --- r? `@wesleywiser` Tacking Issue: rust-lang#54503 Stabilization Report: rust-lang#54503 (comment) Documentation Update: rust-lang/reference#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
…-false-positive, r=blyxyas
Fix doc_markdown DevOps false positive
This fixes an issue where the word "DevOps" ends up as a false positive for the `doc_markdown` lint.
In a doc comment like this
```rust
/// Call the Azure DevOps REST API.
pub fn example() {}
```
the word "DevOps" is highlighted as something which should be in backticks.
```
warning: item in documentation is missing backticks
--> src/lib.rs:1:20
|
1 | /// Call the Azure DevOps REST API.
| ^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_markdown
= note: requested on the command line with `-W clippy::doc-markdown`
help: try
|
1 | /// Call the Azure `DevOps` REST API.
| ~~~~~~~~
warning: `example` (lib) generated 1 warning (run `cargo clippy --fix --lib -p example` to apply 1 suggestion)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
```
This could be overriden with the `doc-valid-idents` configuration parameter as noted by the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#/doc_markdown), but I believe the word "DevOps" is sufficiently common to belong alongside exceptions like "GitHub" and "GitLab".
changelog: [`doc_markdown`]: Fix DevOps false positive.
bump strip-ansi-escapes This bumps `strip-ansi-escapes` to remove arrayvec from it's deps (luser/strip-ansi-escapes#8) Should Cargo.lock be commited too to track it's working state? changelog: none
Rustup r? `@ghost` changelog: none
rustbot
added
the
S-waiting-on-review
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
@bors r+ p=1 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (9c3bc80): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 695.757s -> 697.882s (0.31%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? @Manishearth