Clippy subtree update #125764
Merged
Clippy subtree update #125764
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
The utility function `clippy_utils::fulfill_or_allowed` is not used because using it would require to move the check for allowed after the check iterating over all inherent impls of the type, doing possibly unnecessary work. Instead, `is_lint_allowed` is called as before, but additionally, once certain that the lint should be emitted, `span_lint_hir_and_then` is called instead of `span_lint_and_help` to also fulfill expectations. fixes: rust-lang#12802 changelog: fulfill expectations in `check_unsafe_derive_deserialize`
Adding `#![feature(lint_reasons)]` to the top of the file also changed the line numbers in the expected error output.
…=jackh726 Rename Unsafe to Safety Alternative to rust-lang#124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks. This leaves us today with: ```rust enum ast::Safety { Unsafe(Span), Default, // Safe (going to be added for unsafe extern blocks) } enum hir::Safety { Unsafe, Safe, } ``` We would convert from `ast::Safety::Default` into the right Safety level according the context.
…n using generics' attributes
…ompiler-errors chore: Remove repeated words (extension of rust-lang#124924) When I saw rust-lang#124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing. Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#124948 (chore: Remove repeated words (extension of rust-lang#124924)) - rust-lang#124992 (Add example to IsTerminal::is_terminal) - rust-lang#125279 (make `Debug` impl for `Term` simpler) - rust-lang#125286 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Remove `Rvalue::CheckedBinaryOp` Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996> cc `@RalfJung` While it's a draft, r? ghost
fulfill expectations in `check_unsafe_derive_deserialize` The utility function `clippy_utils::fulfill_or_allowed` is not used because using it would require to move the check for allowed after the check iterating over all inherent impls of the type, doing possibly unnecessary work. Instead, `is_lint_allowed` is called as before, but additionally, once certain that the lint should be emitted, `span_lint_hir_and_then` is called instead of `span_lint_and_help` to also fulfill expectations. Note: as this is my first contribution, please feel free to nitpick or request changes. I am happy to adjust the implementation. fixes: rust-lang#12802 changelog: fulfill expectations in [`unsafe_derive_deserialize`]
And explain when it should be used.
…s, r=Manishearth bug fix: lint numbered_fields message error fixes rust-lang#12367 changelog: [`numbered_fields`]: fix macro expand message error.
* Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”. * Discuss why one would use `!`, a newtype struct, or keep the enum. * Add links to relevant documentation.
* instead simply set the primary message inside the lint decorator functions * it used to be this way before [#]101986 which introduced `msg` to prevent good path delayed bugs (which no longer exist) from firing under certain circumstances when lints were suppressed / silenced * this is no longer necessary for various reasons I presume * it shaves off complexity and makes further changes easier to implement
Rephrase and expand `empty_enum` documentation. * Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”. * Discuss why one would use `!`, a newtype struct, or keep the enum. * Add links to relevant documentation. Before writing this change, I asked the community via [IRLO](https://internals.rust-lang.org/t/idiomatic-definition-of-uninhabited-never-newtypes/20877) and [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Never.20type.20wrappers.20.2F.20defining.20uninhabited.20newtypes) for feedback. The broad consensus seemed to me to be that in a world where both `never_type` and `min_exhaustive_patterns` are stable and therefore available for general use, we _might_ want to `!` or newtypes of it — but it's certainly not “conventional” _yet._ Therefore, I've removed “conventional” and added a discussion of the pros and cons of different choices. changelog: [`empty_enum`]: expanded documentation
…this?” The `restriction` group contains many lints which are not about necessarily “bad” things, but style choices — perhaps even style choices which contradict conventional Rust style — or are otherwise very situational. This results in silly wording like “Why is this bad? It isn't, but ...”, which I’ve seen confuse a newcomer at least once. To improve this situation, this commit replaces the “Why is this bad?” section heading with “Why restrict this?”, for most, but not all, restriction lints. I left alone the ones whose placement in the restriction group is more incidental. In order to make this make sense, I had to remove the “It isn't, but” texts from the contents of the sections. Sometimes further changes were needed, or there were obvious fixes to make, and I went ahead and made those changes without attempting to split them into another commit, even though many of them are not strictly necessary for the “Why restrict this?” project.
…m, r=compiler-errors
Remove `DefId` from `EarlyParamRegion`
Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.
This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes
I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.
Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.
This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.
Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`
r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
add parentheses to [`let_and_return`]'s suggestion closes: rust-lang#12801 --- changelog: suggest adding parentheses when linting [`let_and_return`] and [`needless_return`]
[perf] Delay the construction of early lint diag structs Attacks some of the perf regressions from rust-lang#124417 (comment). See individual commits for details. The first three commits are not strictly necessary. However, the 2nd one (06bc4fc, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement. It's also pretty sweet on its own if I may say so myself.
book: Fix example code Fix example code of the "Disabling evaluation of certain code" section in the configuration chapter. changelog: none
…interaction, r=y21 Fix `unnecessary_to_owned` interaction with macro expansion fixes rust-lang#12821 In the case of an unnecessary `.iter().cloned()`, the lint `unnecessary_to_owned` might suggest to remove the `&` from references without checking if such references are inside a macro expansion. This can lead to unexpected behavior or even broken code if the lint suggestion is applied blindly. See issue rust-lang#12821 for an example. This PR checks if such references are inside macro expansions and skips this part of the lint suggestion in these cases. changelog: [`unnecessary_to_owned`]: Don't suggest to remove `&` inside macro expansion
…s, r=y21 Suppress `iter_on_empty_collections` if the iterator's concrete type is relied upon changelog: fixed rust-lang#12807
… r=Alexendoo [`many_single_char_names`]: Deduplicate diagnostics Relates to rust-lang#12379 Fix `many_single_char_names` lint so that it doesn't emit diagnostics when the current level of the scope doesn't contain any single character name. ```rust let (a, b, c, d): (i32, i32, i32, i32); match 1 { 1 => (), e => {}, } ``` produced the exact same MANY_SINGLE_CHAR_NAMES diagnostic at each of the Arm `e => {}` and the Block `{}`. --- changelog: [`many_single_char_names`]: Fix duplicate diagnostics
don't inhibit random field reordering on repr(packed(1)) `inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in rust-lang#48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time). We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort. This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html): > On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
Rustup r? `@ghost` changelog: none
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
@bors r+ p=1 |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (7feb191): 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. CyclesResults (secondary 2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.847s -> 670.972s (0.17%) |
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jun 13, 2024
…nishearth Clippy subtree update r? `@Manishearth`
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