Rollup of 9 pull requests #101246

- only compare where predicates to trait bounds when generating where clause specific message to fix rust-lang#9151 - use comparable_trait_ref to account for trait bound generics to fix rust-lang#8757

.

…repr(C)` type is compatible with the other type

…d_repr`

This enables more thorough checking of types to avoid triggering on custom Some and None enum variants

Fixes rust-lang#9193

It is passed an argument that is never used.

…jgillot Simplify visitors By removing some unused arguments. r? `@cjgillot`

Update Clippy r? `@Manishearth`

Extend `if_then_some_else_none` to also suggest `bool::then_some` Closes rust-lang#9094. changelog: Extend `if_then_some_else_none` to also suggest `bool::then_some`

1.63 Changelog r? `@xFrednet` changelog: none [Rendered](https://github.com/flip1995/rust-clippy/blob/changelog/CHANGELOG.md)

Update lint versions for 1.63 release r? `@xFrednet` changelog: none

…, r=flip1995 Fixes [`trait_duplication_in_bounds`] false positives Fixes rust-lang#9076 rust-lang#9151 rust-lang#8757. Partially fixes rust-lang#8771. changelog: [`trait_duplication_in_bounds`]: Reduce number of false positives.

Add lint recommending using `std::iter::once` and `std::iter::empty` ``` changelog: [`iter_once`]: add new lint changelog: [`iter_empty`]: add new lint ``` fixes rust-lang#9186 - \[ ] Followed [lint naming conventions][lint_naming] - \[x] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[x] Executed `cargo dev update_lints` - \[x] Added lint documentation - \[x] Run `cargo dev fmt` [lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints The lint doesn't really follow the naming conventions. I don't have any better idea so I'm open to suggestions.

Signed-off-by: xphoniex <dj.2dixx@gmail.com>

… r=cjgillot Visit attributes in more places. This adds 3 loosely related changes (I can split PRs if desired): - Attribute checking on pattern struct fields. - Attribute checking on struct expression fields. - Lint level visiting on pattern struct fields, struct expression fields, and generic parameters. There are still some lints which ignore lint levels in various positions. This is a consequence of how the lints themselves are implemented. For example, lint levels on associated consts don't work with `unused_braces`.

Skip `unnecessary_to_owned` when `t != t.to_string()` Fixes rust-lang#9317 changelog: [`unnecessary_to_owned`]: none

Co-authored-by: Fridtjof Stoldt <xFrednet@gmail.com>

Fix if_let_mutex not checking Mutexes behind refs Fixes rust-lang#9193 We can always peel references because we are looking for a method-call, for which autoderef applies. --- changelog: [`if_let_mutex`]: detect calls to `Mutex::lock()` if mutex is behind a ref changelog: [`if_let_mutex`]: Add labels to the two instances of the same Mutex that will deadlock

…e-extra-deref-from-example, r=giraffate Remove extra dereference from the borrow_deref_ref lint example I don't think such minor change should be mentioned in the changelog. changelog: none

- Rename `ast::Lit::token` as `ast::Lit::token_lit`, because its type is `token::Lit`, which is not a token. (This has been confusing me for a long time.) reasonable because we have an `ast::token::Lit` inside an `ast::Lit`. - Rename `LitKind::{from,to}_lit_token` as `LitKind::{from,to}_token_lit`, to match the above change and `token::Lit`.

…=dswij Add new lint [`positional_named_format_parameters`] *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: Add new lint [`positional_named_format_parameters`] to warn when named parameters in format strings are used as positional arguments.

Fix example The example didn't show the actual problem [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9d0e0727ca5bbd854767f50da693ca0f) changelog: none

Currently, case_sensitive_file_extension_comparisons suggests using `map(..).unwrap_or(..)` which trips up `map_unwrap_or`. This updates the suggestion to use map_or.

…Alexendoo Fix [`non_ascii_literal`] in tests changelog: Don't lint [`non_ascii_literal`] when using non-ascii comments in tests changelog: Don't lint [`non_ascii_literal`] when `allow`ed on tests closes: rust-lang#7739 closes: rust-lang#8263

…anishearth Use `CARGO_TARGET_DIR` in compile-test changelog: none I have a global `CARGO_TARGET_DIR` set, but forgot to delete the old target dir. `compile-test` was getting tripped up on an outdated `rustfix_missing_coverage.txt` I had in there, keeping me from running tests 😄.

…rap_or, r=giraffate suggest map_or in case_sensitive_file_extension_comparisons changelog: [`case_sensitive_file_extension_comparisons `]: updated suggestion in the example to use `map_or` Currently, case_sensitive_file_extension_comparisons suggests using `map(..).unwrap_or(..)` which trips up the `map_unwrap_or` lint. This updates the suggestion to use `map_or`.

du -> due

Handle `CARGO_TARGET_DIR` not being set in compile-test changelog: None

Fix typo in as_undescore docs *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: none

…trochenkov Clean up `LitKind` r? ``@petrochenkov``

`transmute_undefined_repr` fix changelog: Don't lint `transmute_undefined_repr` when the the first field of a `repr(C)` type is compatible with the other type

…owed

unwrap_used and expect_used: trigger on uses of their _err variants changelog: [`unwrap_used`]: lint uses of `unwrap_err` changelog: [`expect_used`]: lint uses of `expect_err` fixes rust-lang#9331

…rcho Enhance `needless_borrow` to consider trait implementations The proposed enhancement causes `needless_borrow` to suggest removing `&` from `&e` when `&e` is an argument position requiring trait implementations, and `e` implements the required traits. Example: ``` error: the borrowed expression implements the required traits --> $DIR/needless_borrow.rs:131:51 | LL | let _ = std::process::Command::new("ls").args(&["-a", "-l"]).status().unwrap(); | ^^^^^^^^^^^^^ help: change this to: `["-a", "-l"]` ``` r? `@Jarcho` changelog: Enhance `needless_borrow` to consider trait implementations

Fixes rust-lang#9347 Technically it is possible to have a blank match-pattern that does nothing, and we fail to lint. But its easier to be safe than sorry here.

Don't lint on match pattern-binding in ´question_mark` Fixes rust-lang#9347 Technically it is possible to have a blank match-pattern that does nothing, and we fail to lint. But it's easier to be safe than sorry here. changelog: [`question_mark`]: don't lint `if let`s with subpatterns

…ing-creation, r=dswij Add `manual_empty_string_creations` lint Closes rust-lang#2972 - [x] Followed [lint naming conventions][lint_naming] - [x] Added passing UI tests (including committed `.stderr` file) - [x] `cargo test` passes locally - [x] Executed `cargo dev update_lints` - [x] Added lint documentation - [x] Run `cargo dev fmt` changelog: [`manual_empty_string_creations`]: Add lint for empty String not being created with `String::new()`

More lint pass merges changelog: None

Refactor `FormatArgsExpn` It now for each format argument `{..}` has: - The `Expr` it points to, and how it does so (named/named inline/numbered/implicit) - The parsed `FormatSpec` (format trait/fill/align/etc., the precision/width and any value they point to) - Many spans The caller no longer needs to pair up arguments to their value, or separately interpret the `specs` `Expr`s when it isn't `None` The gist is that it combines the result of [`rustc_parse_format::Parser`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse_format/struct.Parser.html) with the macro expansion itself This unfortunately makes the code a bit longer, however we need to use both as neither have all the information we're after. `rustc_parse_format` doesn't have the information to resolve named arguments to their values. The macro expansion doesn't contain whether the positions are implicit/numbered/named, or the spans for format arguments Wanted by rust-lang#9233 and rust-lang#8518 to be able to port the changes from rust-lang#9040 Also fixes rust-lang#8643, previously the format args seem to have been paired up with the wrong values somehow changelog: [`format_in_format_args`]: Fix false positive due to misattributed arguments r? `@flip1995` cc `@nyurik`

Rework `only_used_in_recursion` fixes rust-lang#8782 fixes rust-lang#8629 fixes rust-lang#8560 fixes rust-lang#8556 This is a complete rewrite of the lint. This loses some capabilities of the old implementation. Namely the ability to track through tuple and slice patterns, as well as the ability to trace through assignments. The two reported bugs are fixed with this. One was caused by using the name of the method rather than resolving to the `DefId` of the called method. The second was cause by using the existence of a cycle in the dependency graph to determine whether the parameter was used in recursion even though there were other ways to create a cycle in the graph. Implementation wise this switches from using a visitor to walking up the tree from every use of each parameter until it has been determined the parameter is used for something other than recursion. This is likely to perform better as it avoids walking the entire function a second time, and it is unlikely to walk up the HIR tree very much. Some cases would perform worse though. cc `@buttercrab` changelog: Scale back `only_used_in_recursion` to fix false positives changelog: Move `only_used_in_recursion` back to `complexity`

Add [`unused_peekable`] lint changelog: Add [`unused_peekable`] lint closes: rust-lang#854

Fix typos changelog: none

…lip1995 Lint `collapsible_str_replace` fixes rust-lang#6651 ``` changelog: [`collapsible_str_replace`]: create new lint `collapsible_str_replace` ``` If you added a new lint, here's a checklist for things that will be checked during review or continuous integration. - \[x] Followed [lint naming conventions][lint_naming] - \[x] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[ ] Executed `cargo dev update_lints` - \[x] Added lint documentation - \[x] Run `cargo dev fmt`

Add test for rust-lang#8855 Fix rust-lang#8855 Here is what I think is going on. First, the expression `format!("{:>6} {:>6}", a, b.to_string())` expands to: ```rust { let res = ::alloc::fmt::format(::core::fmt::Arguments::new_v1_formatted(&["", " "], &[::core::fmt::ArgumentV1::new_display(&a), ::core::fmt::ArgumentV1::new_display(&b.to_string())], &[::core::fmt::rt::v1::Argument { position: 0usize, format: ::core::fmt::rt::v1::FormatSpec { fill: ' ', align: ::core::fmt::rt::v1::Alignment::Right, flags: 0u32, precision: ::core::fmt::rt::v1::Count::Implied, width: ::core::fmt::rt::v1::Count::Is(6usize), }, }, ::core::fmt::rt::v1::Argument { position: 1usize, format: ::core::fmt::rt::v1::FormatSpec { fill: ' ', align: ::core::fmt::rt::v1::Alignment::Right, flags: 0u32, precision: ::core::fmt::rt::v1::Count::Implied, width: ::core::fmt::rt::v1::Count::Is(6usize), }, }], unsafe { ::core::fmt::UnsafeArg::new() })); res } ``` When I dump the expressions that get past the call to `has_string_formatting` [here](https://github.com/rust-lang/rust-clippy/blob/b312ad7d0cf0f30be2bd4658b71a3520a2e76709/clippy_lints/src/format_args.rs#L83), I see more than I would expect. In particular, I see this subexpression of the above: ``` &[::core::fmt::ArgumentV1::new_display(&a), ::core::fmt::ArgumentV1::new_display(&b.to_string())], ``` This suggests to me that more expressions are getting past [this call](https://github.com/rust-lang/rust-clippy/blob/b312ad7d0cf0f30be2bd4658b71a3520a2e76709/clippy_lints/src/format_args.rs#L71) to `FormatArgsExpn::parse` than should. Those expressions are then visited, but no `::core::fmt::rt::v1::Argument`s are found and pushed [here](https://github.com/rust-lang/rust-clippy/blob/b312ad7d0cf0f30be2bd4658b71a3520a2e76709/clippy_utils/src/macros.rs#L407). As a result, the expressions appear unformatted, hence, the false positive. My proposed fix is to restrict `FormatArgsExpn::parse` so that it only matches `Call` expressions. cc: `@akanalytics` changelog: none

and add test case for `Result`

check for if-some-or-ok-else-none-or-err fixes: rust-lang#8492 --- changelog: make [`option_if_let_else`] to check for match expression with both Option and Result; **TODO: Change lint name? Add new lint with similar functionality?**

Only check for the kind of loop once instead of re-desugaring it.

feat(fix): Do not lint if the target code is inside a loop close rust-lang#8753 we consider the following code. ```rust fn main() { let vec = vec![1]; let w: Vec<usize> = vec.iter().map(|i| i * i).collect(); // <- once. for i in 0..2 { let _ = w.contains(&i); } } ``` and the clippy will issue the following warning. ```rust warning: avoid using `collect()` when not needed --> src/main.rs:3:51 | 3 | let w: Vec<usize> = vec.iter().map(|i| i * i).collect(); | ^^^^^^^ ... 6 | let _ = w.contains(&i); | -------------- the iterator could be used here instead | = note: `#[warn(clippy::needless_collect)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_collect help: check if the original Iterator contains an element instead of collecting then checking | 3 ~ 4 | 5 | for i in 0..2 { 6 ~ let _ = vec.iter().map(|i| i * i).any(|x| x == i); ``` Rewrite the code as indicated. ```rust fn main() { let vec = vec![1]; for i in 0..2 { let _ = vec.iter().map(|i| i * i).any(|x| x == i); // <- execute `map` every loop. } } ``` this code is valid in the compiler, but, it is different from the code before the rewrite. So, we should not lint, If `collect` is outside of a loop. Thank you in advance. --- changelog: Do not lint if the target code is inside a loop in `needless_collect`

Fix false positives of needless_match closes: rust-lang#9084 made needless_match take into account arm in the form of `_ if => ...` changelog: none

Fix `to_string_in_format_args` false positive Fix rust-lang#9256 changelog: none

Because it's never used meaningfully.

Rename `manual_empty_string_creation` and move to pedantic Renames it to `manual_string_new` and moves it to the pedantic category Pedantic because it's a fairly minor style change but could be very noisy changelog: *doesn't need its own entry, but remember to s/manual_empty_string_creation/manual_string_new/ the changelog entry for rust-lang#9295* r? `@xFrednet` to get it in before the upcoming sync as this isn't a `cargo dev rename_lint` style rename

# Stabilization proposal The feature was implemented in rust-lang#50045 by est31 and has been in nightly since 2018-05-16 (over 4 years now). There are [no open issues][issue-label] other than the tracking issue. There is a strong consensus that `break` is the right keyword and we should not use `return`. There have been several concerns raised about this feature on the tracking issue (other than the one about tests, which has been fixed, and an interaction with try blocks, which has been fixed). 1. nrc's original comment about cost-benefit analysis: rust-lang#48594 (comment) 2. joshtriplett's comments about seeing use cases: rust-lang#48594 (comment) 3. withoutboats's comments that Rust does not need more control flow constructs: rust-lang#48594 (comment) Many different examples of code that's simpler using this feature have been provided: - A lexer by rpjohnst which must repeat code without label-break-value: rust-lang#48594 (comment) - A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: rust-lang#48594 (comment). This particular case would also work if `try` blocks were stabilized (at the cost of making the code harder to optimize). - Several examples by JohnBSmith: rust-lang#48594 (comment) - Several examples by Centril: rust-lang#48594 (comment) - An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: rust-lang#48594 (comment) - Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: rust-lang#48594 (comment) Additionally, petrochenkov notes that this is strictly more powerful than labelled loops due to macros which accidentally exit a loop instead of being consumed by the macro matchers: rust-lang#48594 (comment) nrc later resolved their concern, mostly because of the aforementioned macro problems. joshtriplett suggested that macros could be able to generate IR directly (rust-lang#48594 (comment)) but there are no open RFCs, and the design space seems rather speculative. joshtriplett later resolved his concerns, due to a symmetry between this feature and existing labelled break: rust-lang#48594 (comment) withoutboats has regrettably left the language team. joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: rust-lang#48594 (comment) [issue-label]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-label_break_value+ ## Report + Feature gate: - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/src/test/ui/feature-gates/feature-gate-label_break_value.rs + Diagnostics: - https://github.com/rust-lang/rust/blob/6b2d3d5f3cd1e553d87b5496632132565b6779d3/compiler/rustc_parse/src/parser/diagnostics.rs#L2629 - https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L749 - https://github.com/rust-lang/rust/blob/f65bf0b2bb1a99f73095c01a118f3c37d3ee614c/compiler/rustc_resolve/src/diagnostics.rs#L1001 - https://github.com/rust-lang/rust/blob/111df9e6eda1d752233482c1309d00d20a4bbf98/compiler/rustc_passes/src/loops.rs#L254 - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L2079 - https://github.com/rust-lang/rust/blob/d695a497bbf4b20d2580b75075faa80230d41667/compiler/rustc_parse/src/parser/expr.rs#L1569 + Tests: - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs - https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs ## Interactions with other features Labels follow the hygiene of local variables. label-break-value is permitted within `try` blocks: ```rust let _: Result<(), ()> = try { 'foo: { Err(())?; break 'foo; } }; ``` label-break-value is disallowed within closures, generators, and async blocks: ```rust 'a: { || break 'a //~^ ERROR use of unreachable label `'a` //~| ERROR `break` inside of a closure } ``` label-break-value is disallowed on [_BlockExpression_]; it can only occur as a [_LoopExpression_]: ```rust fn labeled_match() { match false 'b: { //~ ERROR block label not supported here _ => {} } } macro_rules! m { ($b:block) => { 'lab: $b; //~ ERROR cannot use a `block` macro fragment here unsafe $b; //~ ERROR cannot use a `block` macro fragment here |x: u8| -> () $b; //~ ERROR cannot use a `block` macro fragment here } } fn foo() { m!({}); } ``` [_BlockExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html [_LoopExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/loop-expr.html

This removes some code we don't need and the method syntax is also more readable IMO.

Replace `contains_ty(..)` with `Ty::contains(..)` This removes some code we don't need and the method syntax is also more readable IMO. changelog: none

… r=petrochenkov Stabilize `#![feature(label_break_value)]` See the stabilization report in rust-lang#48594 (comment).

Quick documentation fix: `Vec::spare_capacity_mut` no longer needs nightly.

new lint This fixes rust-lang#6576 If you added a new lint, here's a checklist for things that will be checked during review or continuous integration. - \[x] Followed [lint naming conventions][lint_naming] - \[x] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[x] Executed `cargo dev update_lints` - \[x] Added lint documentation - \[x] Run `cargo dev fmt` --- changelog: add [`multi_assignments`] lint

uninit_vec: Vec::spare_capacity_mut is stable Quick documentation fix: `Vec::spare_capacity_mut` no longer needs nightly. changelog: none

Fixes rust-lang#9361

… on a `Cow`. This is done because `to_owned` is very similarly named to `into_owned`, but the effect of calling those two methods is completely different. This creates confusion (stemming from the ambiguity of the 'owned' term in the context of `Cow`s) and might not be what the writer intended.

Don't lint `needless_return` if `return` has attrs Fixes rust-lang#9361 The lint used to have a mechanic to allow `cfg`-attrs on naked `return`-statements. This was well-intentioned, yet we can have any kind of attribute, e.g. `allow`, `expect` or even custom `derive`. So the mechanic was simply removed. We now never lint on a naked `return`-statement that has attributes on it. Turns out that the ui-test had a Catch22 in it: In `check_expect()` the `#[expect(clippy::needless_return)]` is an attribute on the `return` statement that can and will be rustfixed away without side effects. But any other attribute would also have been removed, which is what rust-lang#9361 is about. The test proved the wrong thing. Removed the test, the body is tested elsewhere as well. changelog: Ignore [`needless_return`] on `return`s with attrs

Implemented `suspicious_to_owned` lint to check if `to_owned` is called on a `Cow` changelog: Add lint ``[`suspicious_to_owned`]`` ----------------- Hi, posting this unsolicited PR as I've been burned by this issue :) Being unsolicited, feel free to reject it or reassign a different lint level etc. This lint checks whether `to_owned` is called on `Cow<'_, _>`. This is done because `to_owned` is very similarly named to `into_owned`, but the effect of calling those two methods is completely different (one makes the `Cow::Borrowed` into a `Cow::Owned`, the other just clones the `Cow`). If the cow is then passed to code for which the type is not checked (e.g. generics, closures, etc.) it might slip through and if the cow data is coming from an unsafe context there is the potential for accidentally cause undefined behavior. Even if not falling into this painful case, there's really no reason to call `to_owned` on a `Cow` other than confusing people reading the code: either `into_owned` or `clone` should be called. Note that this overlaps perfectly with `implicit_clone` as a warning, but `implicit_clone` is classified pedantic (while the consequences for `Cow` might be of a wider blast radius than just pedantry); given the overlap, I set-up the lint so that if `suspicious_to_owned` triggers `implicit_clone` will not trigger. I'm not 100% sure this is done in the correct way (I tried to copy what other lints were doing) so please provide feedback on it if it isn't. ### Checklist - \[x] Followed [lint naming conventions][lint_naming] - \[x] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[x] Executed `cargo dev update_lints` - \[x] Added lint documentation - \[x] Run `cargo dev fmt`

Ignore `match_like_matches_macro` when there is comment Closes rust-lang#9164 changelog: [`match_like_matches_macro`] is ignored when there is some comment inside the match block. Also add `span_contains_comment` util to check if given span contains comments.

Don't lint literal `None` from expansion This addresses rust-lang/rust-clippy#9288 (comment): If the literal `None` is from expansion, we never lint. This is correct because e.g. replacing the call to `option_env!` with whatever that macro expanded to at the time of linting is certainly wrong. changelog: Don't lint [`partialeq_to_none`] for macro-expansions

Rustup Hopefully this is done right. changelog: None

…ns, r=Alexendoo remove parenthesis from `unnecessary_cast` suggestion This fixes rust-lang#9380. --- changelog: none

Fixes rust-lang#9391

Co-authored-by: Alex Macleod <alex@macleod.io>

…exendoo New lint: Raw slice pointer cast Adds a lint to check for a raw slice being created and cast back to a pointer, suggesting `ptr::slice_from_raw_parts`, to identify UB such as thomcc/rust-typed-arena#54. ``` changelog: [`cast_slice_from_raw_parts`]: Add lint to check for `slice::from_raw_parts(.., ..) as *const _` ```

…Manishearth Fix `suspicious_to_owned` test when `c_char` is `u8` e.g. on aarch64 linux changelog: none

Fix missing parens in `suboptimal_flops` suggestion Fixes rust-lang#9391. The problem is simple enough, I didn't check if the same problem occurs elsewhere, though. changelog: fix missing parenthesis in `suboptimal_flops` suggestion

* Emit the lint in source order * Make suggestions with multiple traits be in source order rather than alphabetical

Initial implementation `result_large_err` This is a shot at rust-lang#6560, rust-lang#4652, and rust-lang#3884. The lint checks for `Result` being returned from functions/methods where the `Err` variant is larger than a configurable threshold (the default of which is 128 bytes). There has been some discussion around this, which I'll try to quickly summarize: * A large `Err`-variant may force an equally large `Result` if `Err` is actually bigger than `Ok`. * There is a cost involved in large `Result`, as LLVM may choose to `memcpy` them around above a certain size. * We usually expect the `Err` variant to be seldomly used, but pay the cost every time. * `Result` returned from library code has a high chance of bubbling up the call stack, getting stuffed into `MyLibError { IoError(std::io::Error), ParseError(parselib::Error), ...}`, exacerbating the problem. This PR deliberately does not take into account comparing the `Ok` to the `Err` variant (e.g. a ratio, or one being larger than the other). Rather we choose an absolute threshold for `Err`'s size, above which we warn. The reason for this is that `Err`s probably get `map_err`'ed further up the call stack, and we can't draw conclusions from the ratio at the point where the `Result` is returned. A relative threshold would also be less predictable, while not accounting for the cost of LLVM being forced to generate less efficient code if the `Err`-variant is _large_ in absolute terms. We lint private functions as well as public functions, as the perf-cost applies to in-crate code as well. In order to account for type-parameters, I conjured up `fn approx_ty_size`. The function relies on `LateContext::layout_of` to compute the actual size, and in case of failure (e.g. due to generics) tries to come up with an "at least size". In the latter case, the size of obviously wrong, but the inspected size certainly can't be smaller than that. Please give the approach a heavy dose of review, as I'm not actually familiar with the type-system at all (read: I have no idea what I'm doing). The approach does, however flimsy it is, allow us to successfully lint situations like ```rust pub union UnionError<T: Copy> { _maybe: T, _or_perhaps_even: (T, [u8; 512]), } // We know `UnionError<T>` will be at least 512 bytes, no matter what `T` is pub fn param_large_union<T: Copy>() -> Result<(), UnionError<T>> { Ok(()) } ``` I've given some refactoring to `functions/result_unit_err.rs` to re-use some bits. This is also the groundwork for rust-lang#6409 The default threshold is 128 because of rust-lang/rust-clippy#4652 (comment) `lintcheck` does not trigger this lint for a threshold of 128. It does warn for 64, though. The suggestion currently is the following, which is just a placeholder for discussion to be had. I did have the computed size in a `span_label`. However, that might cause both ui-tests here and lints elsewhere to become flaky wrt to their output (as the size is platform dependent). ``` error: the `Err`-variant returned via this `Result` is very large --> $DIR/result_large_err.rs:36:34 | LL | pub fn param_large_error<R>() -> Result<(), (u128, R, FullyDefinedLargeError)> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The `Err` variant is unusually large, at least 128 bytes ``` changelog: Add [`result_large_err`] lint

Fix the emission order of `trait_duplication_in_bounds` Makes the lint emit in source order rather than whatever order the hash map happens to be in. This is currently blocking the sync into rustc. changelog: None

Before, the text simply asked people to use a symbol which is hard to search for. Now the text links back to the chapter on error propagation in The Book. That should help people find the relevant keywords for further searches.

This commit removes many cases of MIR opt tests emitting `.diff`s for more than one pass. These tests cannot be `unit-test`s, and so they are easy to break, and they also provide little value due to having excessively strong opinions over *how* a piece of code should be optimized. Where reasonable, we instead add separate test files that only emit the `PreCodegen.after` MIR for code where we want to track what the result of the net result of the optimization pipeline's output is.

with manual impl SessionDiagnostic

Co-authored-by: David Wood <agile.lion3441@fuligin.ink>

fixes `SessionSubdiagnostic` to accept multiple attributes emitting list of fluent message remains unresolved

Functions annotated with `#[rustc_lint_diagnostics]` are used by the diagnostic migration lints to know when to lint, but functions that are annotated with this attribute shouldn't themselves be linted. Signed-off-by: David Wood <david.wood@huawei.com>

…, r=petrochenkov Pretty printing give proper error message without panic Fixes rust-lang#100770

…iser Simplify MIR opt tests This commit removes many cases of MIR opt tests emitting `.diff`s for more than one pass. These tests cannot be `unit-test`s, and so they are easy to break, and they also provide little value due to having excessively strong opinions over *how* a piece of code should be optimized. Where reasonable, we instead add separate test files that only emit the `PreCodegen.after` MIR for code where we want to track what the end to end effect of the optimization pipeline on the example code is. r? ``@wesleywiser``

…-when-appropriate, r=davidtwco Suggest moving redundant generic args of an assoc fn to its trait Closes rust-lang#89064

migrate rustc_query_system to use SessionDiagnostic issues: * variable list is not supported in fluent * ~~cannot have two sub diagnostic with the same tag (eg. 2 .note or 2 .help)~~ allow multiple tag with SessionSubdiagnostic derive

Update Clippy r? ``@Manishearth``

Fix uintended diagnostic caused by `drain(..)` Calling `drain(..)` makes later `suggestable_variants.is_empty()` always true, which makes the diagnostics unintended.

Link “? operator” to relevant chapter in The Book Before, the text simply asked people to use a symbol which is hard to search for. Now the text links back to the chapter on error propagation in The Book. That should help people find the relevant keywords for further searches.

…t-no-self-lint, r=fee1-dead lint: avoid linting diag functions with diag lints Functions annotated with `#[rustc_lint_diagnostics]` are used by the diagnostic migration lints to know when to lint, but functions that are annotated with this attribute shouldn't themselves be linted. cc rust-lang#100717 rust-lang#101041 (comment)

Fix a typo on `wasm64-unknown-unknown` doc

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 9 pull requests #101246

Rollup of 9 pull requests #101246

Commits on Aug 2, 2022

Commits on Aug 3, 2022

Commits on Aug 4, 2022

Commits on Aug 7, 2022

Commits on Aug 8, 2022

Commits on Aug 9, 2022

Commits on Aug 10, 2022

Commits on Aug 11, 2022

Commits on Aug 12, 2022

Commits on Aug 13, 2022

Commits on Aug 14, 2022

Commits on Aug 15, 2022

Commits on Aug 16, 2022

Commits on Aug 17, 2022

Commits on Aug 18, 2022

Commits on Aug 19, 2022

Commits on Aug 20, 2022

Commits on Aug 21, 2022

Commits on Aug 22, 2022

Commits on Aug 23, 2022

Commits on Aug 24, 2022

Commits on Aug 25, 2022

Commits on Aug 26, 2022

Commits on Aug 27, 2022

Commits on Aug 28, 2022

Commits on Aug 29, 2022

Commits on Aug 30, 2022

Commits on Aug 31, 2022