-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Clippy subtree update #141343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clippy subtree update #141343
Conversation
It is not enough to check if an expression type implements `Drop` to determine whether it can have a significant side-effect. Also, add tests for unchecked cases which were explicitly handled in the code, such as checking for side effect in a `struct`'s fields, or in its base expression.
A representation attribute `#[repr(…)]` might indicate that the ordering of the fields or the variants is dictated by the API the code is interfacing with. Better not lint with `arbitrary_source_item_ordering` in this case.
Do not attempt to fetch a snippet from expansion. Without this change, the inside of macros could[*] be shown as the source of the problem. [*] Due to the way the source code is processed and reparsed in this macro, the declarative macro has to be located outside the current source file for the bug to appear. Otherwise, the macro call itself will be (mis)identified as a potential `struct` field definition and the lint will not trigger.
A `return` in an expression makes it divergent and cannot be removed blindly. While this stripping might have been introduced as a way to catch more cases, it was improperly used, and no tests exhibit a failure when this special handling is removed.
In this case, a dereference is needed before using `mem::size_of_val()`.
Clippy should not lint 2 blocks expression for comparison_chain.
Using the function declaration, by stripping the body, is enough to convey the lint message.
…ny()` (rust-lang#14800) Fixes: rust-lang/rust-clippy#14656 changelog: Fix [`useless_conversion`] false positive when using `.into_iter().any()`.
Clippy should not lint 2 blocks expression for comparison_chain. Fixes rust-lang/rust-clippy#4725 changelog: [`comparison_chain`]: do not lint 2 blocks expression
`borrow_interior_mutable_const` messages to be less assertive. Update documentation for both lints.
`borrow_interior_mutable_const` to be more thorough on weird constructs
* rename test files inside directories and ui-toml tests * rename tests prefixed with the lint's name * better module path renaming when renaming the lint's module * partially delete lint files when uplifting * rename ui_test error markers
…ust-lang#14637) A large fraction of the lints emitted in CI lintcheck come from [this `match`](https://github.com/unicode-rs/unicode-normalization/blob/v0.1.23/src/tables.rs#L34289), currently for `n` same arms `((n - 1) * n)/2` lints are emitted, with this change it will be emitted as a single lint Also fixes rust-lang/rust-clippy#13835 changelog: none
…ust-lang#14777) Using the function declaration, by stripping the body, is enough to convey the lint message. changelog: [`unnecessary_wraps`]: do not include the whole body in the lint span Closes rust-lang/rust-clippy#14773
Fixes rust-lang/rust-clippy#14750 by reducing the lint span for needless_return. changelog: [`needless_return`]: Lint span no longer wraps to previous line
The `explicit_into_iter_loop`, `explicit_iter_loop` and `iter_next_loop` will now: - trigger only when the triggering expression is not located into macro code; - properly expose code rewrite proposal with code coming from the root context. changelog: [`explicit_into_iter_loop`, `explicit_iter_loop`, `iter_next_loop`]: behave in macro context Fixes rust-lang/rust-clippy#14630
…text (rust-lang#14804) The first commit fixes rust-lang/rust-clippy#14802: when a slice is directly present, it must be dereferenced (instead of referenced -1 times) before being passed to `mem::size_of_val()`. The second commit triggers the lint in a `const` contact when MSRV ≥ 1.85. changelog: [`manual_slice_size_computation`]: fix ICE in suggestion to efficiently compute the size of a slice, and trigger the lint in `const` context as well
r? @ghost Quick out-of cycle sync to fix an ICE that was already reported twice changelog: none
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment was marked as resolved.
This comment was marked as resolved.
0e7bbc1
to
a0c1ed3
Compare
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
@bors r+ p=1 rollup=never |
⌛ Testing commit 0e203f3 with merge bf64d66bd58719fac2585eae5e546e5e1d9947f5... |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 462cc09 (parent) -> bf64d66 (this PR) Test differencesNo test diffs found Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard bf64d66bd58719fac2585eae5e546e5e1d9947f5 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (bf64d66): 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)Results (primary 2.7%, secondary 3.3%)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.
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: 777.166s -> 776.537s (-0.08%) |
Out of cycle sync to fix an ICE that was reported twice already: rust-lang/rust-clippy#14828
r? @Manishearth