-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Clippy subtree update #144449
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 #144449
Conversation
The first non-MSRV-compatible item located under a `#[cfg(…)]` or `#[cfg_attr(…)]` attribute will get an additional note suggesting changing `#[clippy::msrv]` locally.
A later commit will introduce the non-linting of feature-enabled items. Switch to public items from `core` for the tests as to not interfere.
If an item has been enabled through a feature, it will not be linted even though the MSRV is not compatible. This use case may happen when stable compilers are allowed to enable unstable features, e.g. in the Rust for Linux toolchain.
New Rust releases also stabilize enum variants, constants, and so on. Lint them as well.
Also, update error marker for consistency.
To limit false positives, the `range_plus_one` and `range_minus_one` lints will restrict themselves to situations where the iterator types can be easily switched from exclusive to inclusive or vice-versa. This includes situations where the range is used as an iterator, or is used for indexing. Also, when the range is used as a function or method call argument and the parameter type is generic over traits implemented by both kind of ranges, the lint will trigger. On the other hand, assignments of the range to variables, including automatically typed ones or wildcards, will no longer trigger the lint. However, the cases where such an assignment would benefit from the lint are probably rare. This fix doesn't prevent false positives from happening. A more complete fix would check if the obligations can be satisfied by the new proposed range type.
Those lints share the detection logic structure, but differed, probably because of an oversight, in lint emission: only one of them would take care of emitting parentheses around the suggestion if required. Factor the code into one function which checks for the right condition and emits the lint in an identical way.
However, if they appear within the context of a function argument, they will be marked as certain, as they might eventually be considered `i32` by default if the context is not more specific. Also, in the case of binary expressions, if one of the side is uncertain, then the certainty will come from the other side.
`Node::Param(…)` can represent function parameters as well as closure parameters. In the second case, a type is not always given. When no type is given, consider it uncertain.
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing with `a.is_multiple_of(b)`. - In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)` might not be typable. - In `a % b == 0`, `a` and `b` must be unsigned integers, not any arbitrary types implementing `Rem` and outputing an integer.
Removes an unnecessary use of `span_lint_hir_and_then()` where `span_lint_and_then()` would do.
This also moves the lint to be posted on the call.
This removes the need for using source snippets in the replacement.
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment was marked as spam.
This comment was marked as spam.
This comment has been minimized.
This comment has been minimized.
@@ -19,6 +19,7 @@ const IGNORED_RULES_FOR_STD_AND_RUSTC: &[&str] = &[ | |||
"too_many_arguments", | |||
"needless_lifetimes", // people want to keep the lifetimes | |||
"wrong_self_convention", | |||
"approx_constant", // libcore is what defines those |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope this is the right fix 🤔
@bors r+ p=1 roll up=never |
Clippy subtree update r? `@Manishearth`
💔 Test failed - checks-actions |
Not sure if this has to be re-queued |
@bors retry |
☀️ 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 a955f1c (parent) -> 430d6ed (this PR) Test differencesShow 4 test diffs4 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 430d6eddfc6a455ca4a0137c0822a982cccd3b2b --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 (430d6ed): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 4.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
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: 467.355s -> 468.925s (0.34%) |
r? @Manishearth