Update Clippy #85505
Merged
Update Clippy #85505
Conversation
This file contains hidden or 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
Update CHANGELOG.md This changelog is **big**. 🎉 [Rendered](https://github.com/flip1995/rust-clippy/blob/changelog/CHANGELOG.md) changelog: none
…king `self` when non-`Copy` type It relaxes rules for `to_*` variant, so it doesn't lint in trait definitions and implementations anymore. Although, non-`Copy` type implementing trait's `to_*` method taking `self` feels not good (consumes ownership, so should be rather named `into_`), it would be better if this case was a pedantic lint (allow-by-default) instead.
Make `write!(buf, "\n")` suggest `writeln!(buf)` by removing the trailing comma from `writeln!(buf, )`. changelog: [`write_with_newline`] suggestion on only "\n" improved
The most recent changelog update 037ddf2 accompanying the 1.52 release added a second "Rust 1.52" section header, with the result that the Rust release announcement https://blog.rust-lang.org/2021/05/06/Rust-1.52.0.html is linking to the "current beta" changelog section for Clippy rather than the stable changelog. I don't know the release process but based on previous changes to this file, I assume the correct thing to do is to mark the topmost section as being for Rust 1.53, not 1.52.
Fix duplicated "Rust 1.52" version section header The most recent changelog update 037ddf2 accompanying the 1.52 release added a second "Rust 1.52" section header, with the result that the Rust release announcement https://blog.rust-lang.org/2021/05/06/Rust-1.52.0.html is linking to the "current beta" changelog section for Clippy rather than the stable changelog. I don't know the release process but based on previous changes to this file, I assume the correct thing to do is to mark the topmost section as being for Rust 1.53, not 1.52. changelog: none
…ant, r=flip1995 For `to_*` variant don't lint in trait impl taking `self` when non-`Copy` type Lint name: `wrong_self_convention`. It relaxes rules for `to_*` variant, so it doesn't lint in trait definitions and implementations anymore. Although, non-`Copy` type implementing trait's `to_*` method taking `self` feels not good (consumes ownership, so should be rather named `into_`), it would be better if this case was a pedantic lint (allow-by-default) instead. More information in the discussion with `@flip1995` [here](rust-lang/rust-clippy#7002 (comment)) changelog: `wrong_self_convention`: For `to_*` variant don't lint in trait impl taking `self` when non-`Copy` type r? `@flip1995`
Handle write!(buf, "\n") case better Make `write!(buf, "\n")` suggest `writeln!(buf)` by removing the trailing comma from `writeln!(buf, )`. changelog: [`write_with_newline`] suggestion on only "\n" improved
- `len` might produce different results than `count` - they don't have `contain` but `contains_key` method
Those two types are supported already when used indirectly. This commit adds support for direct usage as well.
Fix needless_quesiton_mark false positive changelog: Fix [`needless_question_mark`] false positive where the inner value is implicity dereferenced by the question mark. Fixes rust-lang#7107
The whole point of named fields is that we don't have to worry about order. The names, not the position, communicate the information, so worrying about consistency for consistency's sake is pedantic to a *T*. Fixes rust-lang#7192. wchargin-branch: inconsistent-struct-constructor-pedantic wchargin-source: 4fe078a21c77ceb625e58fa3b90b613fc4fa6a76
Fix stack overflow issue in `redundant_pattern_matching` Fixes rust-lang#7169 ~~cc `@Jarcho` Since tomorrow is release day and we need to get this also fixed in beta, I'll just revert the PR instead of looking into the root issue. Your changes are good, so if you have an idea what could cause this stack overflow and know how to fix it, please open a PR that reverts this revert with a fix.~~ r? `@llogiq` changelog: none (fixes stack overflow, but this was introduced in this release cycle)
Fix duplicate unknown lint errors Fixes rust-lang/rust-clippy#6602
Backport rust-lang#7170 to beta changelog: none (fixes stack overflow, but this was introduced in this release cycle)
remove const_fn feature gate Fixes rust-lang#84510 r? `@oli-obk`
…constructor-pedantic, r=camsteffen Move `inconsistent_struct_constructor` to pedantic The whole point of named fields is that we don't have to worry about order. The names, not the position, communicate the information, so worrying about consistency for consistency's sake is pedantic to a *T*. Cf. rust-lang#7192. changelog: [`inconsistent_struct_constructor`] is moved to pedantic. wchargin-branch: inconsistent-struct-constructor-pedantic
Co-authored-by: Philipp Krones <[email protected]>
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:
```
error[E0412]: cannot find type `MissingType` in this scope
--> $DIR/auxiliary/span-from-proc-macro.rs:37:20
|
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
| ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL | field: MissingType
| ^^^^^^^^^^^ not found in this scope
|
::: $DIR/span-from-proc-macro.rs:8:1
|
LL | #[error_from_attribute]
| ----------------------- in this macro invocation
```
Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`
This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.
This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
macro to get run. This saves all of the sapns in the input to `quote!`
into the metadata of *the proc-macro-crate* (which we are currently
compiling). The `quote!` macro then expands to a call to
`proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.
The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.
This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`
Custom quoting currently has a few limitations:
In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.
Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
…tion, r=flip1995
Metadata collection monster eating deprecated lints
This adds the collection of deprecated lints to the metadata collection monster. The JSON output has the same structure with the *new* lint group "DEPRECATED". Here is one of fourteen examples it was able to dig up in Clippy's code:
```JSON
{
"id": "assign_op_pattern",
"id_span": {
"path": "src/assign_ops.rs",
"line": 34
},
"group": "clippy::style",
"docs": " **What it does:** Checks for `a = a op b` or `a = b commutative_op a` patterns.\n\n **Why is this bad?** These can be written as the shorter `a op= b`.\n\n **Known problems:** While forbidden by the spec, `OpAssign` traits may have\n implementations that differ from the regular `Op` impl.\n\n **Example:**\n ```rust\n let mut a = 5;\n let b = 0;\n // ...\n // Bad\n a = a + b;\n\n // Good\n a += b;\n ```\n",
"applicability": {
"is_multi_part_suggestion": false,
"applicability": "MachineApplicable"
}
}
```
And you! Yes you! Sir or Madam can get all of this **for free** in Clippy if this PR gets merged. (Sorry for the silliness ^^)
---
See: rust-lang#7172 for the full metadata collection to-do list or to suggest a new feature in connection to it 🙃
---
changelog: none
r? `@flip1995`
Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths This PR fixes rust-lang#73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped. `RealFileName::Named` introduced in rust-lang#72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path. `RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure. When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host". `rustc_span::SourceFile`'s fields `unmapped_path` (introduced by rust-lang#44940) and `name_was_remapped` (introduced by rust-lang#41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`. cc `@eddyb` who implemented `/rustc/...` path devirtualisation
Deny warnings in every main sub-crate Pointed out by `@xFrednet` in rust-lang/rust-clippy#7229 (comment) This enables the same (rustc) lints in every main sub-crate: - `clippy` - `clippy_lints` - `clippy_utils` - `clippy_dev` In addition it forwards the `deny-warnings` feature to those sub-crates, so we don't miss warnings that then become a problem during sync. (I wanted to fix that before, but forgot about it, so thanks for pointing it out `@xFrednet!)` changelog: none
async functions always return a value
Fix ICE in `implicit_return` fixes: rust-lang#7231 changelog: Fix ICE in `implicit_return` for async functions
Treat different generic arguments as different types. Allow the lint to be ignored on the type definition, or any impl blocks.
Don't lint `multiple_inherent_impl` with generic arguments fixes: rust-lang#5772 changelog: Treat different generic arguments as different types in `multiple_inherent_impl`
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on rust-lang#84782, which has a PR in rust-lang#84811 Rebased atop that fix. `try_trait_v2` tracking issue: rust-lang#84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
And stripping the clippy:: prefix from the group
Co-authored-by: Philipp Krones <[email protected]>
…, r=flip1995 Adding the default lint level to the metadata collection I noticed while working on the website adaption that the lint groups still had the `clippy::` prefix in the JSON output. This PR removes this prefix and adds a `level` field to each lint and with that simplifies the website display and saves performance. The deprecated lints get are assigned to the level `none`. This is a bit different in comparison to the current lint list, but I believe that this will look better overall. Unless there is any argument against this :). That's it just a small baby PR in comparison to the original monster ^^ --- See: rust-lang#7172 for the full metadata collection to-do list or to suggest a new feature in connection to it. --- changelog: none r? `@flip1995`
Rustup r? `@ghost` cc `@xFrednet` There was a change to the `rustc_span::FileName` removing the `Display` impl for it. I adapted the metadata collector to compile with that change. I'm not sure if I changed the behavior with this. The path to the string is now printed relative to the `clippy_lints` dir. So for example `src/swap.rs`. I think this should be fine, but probably something to be aware of. changelog: none
|
Some changes occurred in src/tools/clippy. cc @rust-lang/clippy |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
|
@bors r+ |
|
📌 Commit 14f55fa has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
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.
Bi-weekly Clippy update
r? @Manishearth