Clippy subtree update #149425
Merged
Clippy subtree update #149425
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
will improve the diff for the next commit
- move `is_allowed_vec_method` (a stripped-down version of it, anyway, as the function doesn't make sense as is out of context) to utils, as it's shared between `useless_vec` and `ptr_arg` - add another test for non-standard macro brace case - rm unneeded `allow`s - rm duplicated tests - add comments to some tests
…ration_sugg` This doesn't change any functionality, but will make it easier to switch to a uniform message in the next commit. Also a nice simplification imo
Diff best seen with whitespace ignored
changelog: [`sliced_string_as_bytes`]: don't fire on `str[..].as_bytes()` So I ran into this in some codebase I was working on, where the lint fired on this line: ```rust let string: &str; string[..].as_bytes() ``` So I was trying to understand the rationale behind this lint, and it says: > It involves doing an unnecessary UTF-8 alignment check which is less efficient, and can cause a panic. This is obviously not true in the case where a `RangeFull` slice is being taken, since there is no UTF-8 boundary check, and no panic can be caused. So I created an exemption for `RangeFull`s. Two other notes: 1. I'm not sure the word "alignment" in the lint's description (quoted above) is really correct, should probably say "char boundary" instead? 2. I might be missing something, but isn't there a lint for doing superfluous slice indexing, and then calling a slice method? e.g. `str[..].len()` or `slice[..].len()`, where `str` and `slice` are `&str` and `&[T]`, respectively. If we had one, I would expect *it* to fire for the example code I quoted above.
This comment has been minimized.
This comment has been minimized.
flip1995
force-pushed
the
clippy-subtree-update
branch
from
08be39b to
0a1fa79
Compare
Collaborator
|
Member
|
@bors r+ p=1 subtree sync |
Collaborator
bors
added
S-waiting-on-bors
Member
|
@bors r+ p=1 rollup=never |
Collaborator
|
💡 This pull request was already approved, no need to approve it again.
|
Collaborator
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
|
lol |
bors
added
S-waiting-on-author
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 29, 2025
…gen-gcc-remove-unnecessary-unwrap, r=workingjubilee Remove an unnecessary `unwrap` in `rustc_codegen_gcc` This should hopefully unblock rust-lang#149425 (I couldn't find an in-flight PR that was already doing this). I've tested locally with the `master` version of Clippy that `rustc_codegen_gcc` passes the lints (the syncing PR could still fail for other reasons however). I understand that `rustc_codegen_gcc` is normally developed [outside of this repo](https://github.com/rust-lang/rustc_codegen_gcc) but my understanding is that that repo is two-way synced regularly and hopefully it is acceptable to do this tiny change here to unblock the Clippy syncing PR (is there an established process for how to unblock these syncing PRs?). Of course feel free to close if this isn't the expected process.
rust-timer
added a commit
that referenced
this pull request
Nov 29, 2025
Rollup merge of #149449 - AudaciousAxiom:refactor/rustc-codegen-gcc-remove-unnecessary-unwrap, r=workingjubilee Remove an unnecessary `unwrap` in `rustc_codegen_gcc` This should hopefully unblock #149425 (I couldn't find an in-flight PR that was already doing this). I've tested locally with the `master` version of Clippy that `rustc_codegen_gcc` passes the lints (the syncing PR could still fail for other reasons however). I understand that `rustc_codegen_gcc` is normally developed [outside of this repo](https://github.com/rust-lang/rustc_codegen_gcc) but my understanding is that that repo is two-way synced regularly and hopefully it is acceptable to do this tiny change here to unblock the Clippy syncing PR (is there an established process for how to unblock these syncing PRs?). Of course feel free to close if this isn't the expected process.
Member
|
lets try this again |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Contributor
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 0ad2cd3 (parent) -> 8a3a6bd (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 8a3a6bdb68b4d4c9ed922840808b02015741331e --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (8a3a6bd): 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: 471.605s -> 471.041s (-0.12%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
33 participants
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
1 day late. Totally forgot about this yesterday.