Clippy subtree update - #159030
Conversation
i.e. rename: - filter_map_next -> filter_map_next_unfixable - filter_map_next_fixable -> filter_map_next This is because having fixable lints is the common case
separate commit to improve diffs
1. In the singe-line case, we switch to verbose suggestions, otherwise the suggestion line gets too long due to the longer message. 2. In the multi-line case, we use span-less help, otherwise the whole multiline span gets highlighted the second time. 3. Also make the suggestion message more concise.
It's a bad name: long, and contains a negative. `skippable_lints` is better.
This used to be a workaround for a rustc diagnostics issue which has since been resolved
…per, r=GuillaumeGomez Update `rustc-literal-escaper` version to `0.0.8` This new version contains a minor performance improvement. More detail in the PR: rust-lang/literal-escaper#27 cc @hkBst r? ghost
Without this change, `single_range_in_vec_init`, and all lints depending on `higher::Range`, will not lint range expressions that use the new `Copy + !Iterator` range types, which occur when `feature(new_range)` is enabled and will occur when using the future edition where that type change is the default, stable behavior. Prior to <rust-lang/rust-clippy#17146>, `single_range_in_vec_init` did detect such ranges (because it looked for the desugaring and not what lang item was involved); therefore, this is also fixing a regression. Note that because the new range types do not implement `Iterator`, the `collect()` suggestion must change. I chose `Vec::from_iter(range)` over `(range).into_iter().collect()` because I believe it is the more elegant (and intended) solution.
…, r=Urgau Rework lint pass running Some cleanups relating to the running of lint passes. r? @Urgau
|
cc @rust-lang/clippy These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
|
|
@bors r+ rollup=never p=1 (subtree update) |
This comment has been minimized.
This comment has been minimized.
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 31e4b84 (parent) -> ae705ae (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 ae705ae862c518e4e1f8ead45777e18cf4b6a271 --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 |
|
Finished benchmarking commit (ae705ae): 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 (primary -2.0%, secondary -2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.0%, secondary -1.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 488.684s -> 491.745s (0.63%) |
Do I understand correctly that this should not impact compiler dependencies in any way? Or are itertools shared between the two? |
Clippy subtree update r? Manishearth Cargo.lock update due to Clippy version bump and itertools version bump in Clippy.
r? Manishearth
Cargo.lock update due to Clippy version bump and itertools version bump in Clippy.