Fixes for latest nightly

Bump nightly version -> 2022-08-27

Merge branch 'master' into rustup

Don't lint literal None from expansion

Auto merge of #9276 - dswij:9164, r=flip1995

Ignore `match_like_matches_macro` when there is comment

Closes #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.

Auto merge of #8984 - xanathar:pr/suspicious_to_owned, r=llogiq

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  when there is comment

Add `span_contains_comments` util

remove parenthesis from unnecessary_cast suggestion

Auto merge of #9381 - lukaslueg:issue9361, r=dswij

Don't lint `needless_return` if `return` has attrs

Fixes #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 #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`.

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 #9361

Auto merge of #9374 - sk1p:patch-1, r=Jarcho

uninit_vec: Vec::spare_capacity_mut is stable

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

changelog: none

Replace `Body::basic_blocks()` with field access

Auto merge of #9379 - royrustdev:multi_assignments, r=llogiq

new lint

This fixes #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

add `multi_assignments` lint

uninit_vec: Vec::spare_capacity_mut is stable

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

Rollup merge of #99332 - jyn514:stabilize-label-break-value, r=petrochenkov

Stabilize `#![feature(label_break_value)]`

See the stabilization report in https://github.com/rust-lang/rust/issues/48594#issuecomment-1186213313.

Auto merge of #9370 - mikerite:20220824_ty_contains, r=Jarcho

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

Replace `contains_ty(..)` with `Ty::contains(..)`

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

Stabilize `#![feature(label_break_value)]`

 # Stabilization proposal

The feature was implemented in https://github.com/rust-lang/rust/pull/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: https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234
2. joshtriplett's comments about seeing use cases: https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176
3. withoutboats's comments that Rust does not need more control flow constructs: https://github.com/rust-lang/rust/issues/48594#issuecomment-450050630

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: https://github.com/rust-lang/rust/issues/48594#issuecomment-422502014
- A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: https://github.com/rust-lang/rust/issues/48594#issuecomment-427628251. 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: https://github.com/rust-lang/rust/issues/48594#issuecomment-434651395
- Several examples by Centril: https://github.com/rust-lang/rust/issues/48594#issuecomment-440154733
- An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: https://github.com/rust-lang/rust/issues/48594#issuecomment-443557569
- Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: https://github.com/rust-lang/rust/issues/48594#issuecomment-1184213006

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: https://github.com/rust-lang/rust/issues/48594#issuecomment-450246249

nrc later resolved their concern, mostly because of the aforementioned macro problems.
joshtriplett suggested that macros could be able to generate IR directly
(https://github.com/rust-lang/rust/issues/48594#issuecomment-451685983) 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: https://github.com/rust-lang/rust/issues/48594#issuecomment-632960804

withoutboats has regrettably left the language team.

joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: https://github.com/rust-lang/rust/issues/48594#issuecomment-1111269353

[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

Auto merge of #9366 - Alexendoo:manual_string_new, r=xFrednet

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 #9295*

r? `@xFrednet` to get it in before the upcoming sync as this isn't a `cargo dev rename_lint` style rename

Rename `manual_empty_string_creation` and move to pedantic

Remove the symbol from `ast::LitKind::Err`.

Because it's never used meaningfully.

Auto merge of #9259 - smoelius:fix-9256, r=llogiq

Fix `to_string_in_format_args` false positive

Fix #9256

changelog: none

`needed_ref` -> `needs_ref`

Fix `to_string_in_format_args` false positive

Auto merge of #9092 - tamaroning:fix-needless-match, r=llogiq

Fix false positives of needless_match

closes: #9084
made needless_match take into account arm in the form of `_ if => ...`

changelog: none

Auto merge of #8992 - kyoto7250:fix_8753, r=flip1995

feat(fix): Do not lint if the target code is inside a loop

close #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`

Improve error if rustfix coverage test spuriously fails

Reduce code duplication

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

Auto merge of #8696 - J-ZhengLi:issue8492, r=flip1995

check for if-some-or-ok-else-none-or-err

fixes: #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?**

Reduce indentation and add comment about lint name

Update needless_match.stderr

and check for `Result`

allow check for `match` in lint [`option_if_let_else`]
and add test case for `Result`

Auto merge of #8857 - smoelius:fix-8855, r=flip1995

Add test for #8855

Fix #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

Add test for #8855

Auto merge of #9269 - nahuakang:collapsible_str_replace, r=flip1995

Lint `collapsible_str_replace`

fixes #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`

Auto merge of #9355 - alex-semenyuk:fixed_typos, r=giraffate

Fix typos

changelog: none

Simplify lint logic and address code review comments

Fix typos

Auto merge of #9258 - Serial-ATA:unused-peekable, r=Alexendoo

Add [`unused_peekable`] lint

changelog: Add [`unused_peekable`] lint
closes: #854

Adjust test cases; run cargo dev bless

Remove checks on char slice; improve lint suggestion

Handle repeated str::replace calls with single char kind to str

Handle replace calls with char slices

Extend and improve initial test cases for collapsible_str_replace

Register new lint collapsible_str_replace to methods

Auto merge of #8804 - Jarcho:in_recursion, r=Alexendoo

Rework `only_used_in_recursion`

fixes #8782
fixes #8629
fixes #8560
fixes #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`

Auto merge of #9349 - Alexendoo:format-args-expn, r=flip1995

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 #9233 and #8518 to be able to port the changes from #9040

Also fixes #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`

Move `only_used_in_recursion` back into `complexity`

Rework `only_used_in_recursion`

Refactor `FormatArgsExpn`

Auto merge of #8957 - Jarcho:more_pass_merges, r=flip1995

More lint pass merges

changelog: None

Move `VerboseFileReads` into `Methods` lint pass

Move `VecResizeToZero` into `Methods` lint pass

Move `UnnecessarySortBy` into `Methods` lint pass

Move `UnitHash` into `Methods` lint pass

Move `TransmutingNull` into `Transmute` lint pass

Move `StableSortPrimitive` to `Methods` lint pass

Move `RepeatOnce` into `Methods` lint pass

Move `range_zip_with_len` into `Methods` lint pass

Move `PathBufPushOverwrite` into `Methods` lint group

Move `OpenOptions` into `Methods` lint pass

Move `MutMutexLock` into `Methods` lint pass

Move `MapErrIgnore` into `Methods` lint pass

Move `MapClone` into `Methods` lint pass

Move `ManualOkOr` into `Methods` lint pass

Move `GetFirst` into `Methods` lint pass

Move `CaseSensitiveFileExtensionComparisons` into `Methods` lint pass

Move `BytesCountToLen` into `Methods` lint pass

Move `ByteCount` into `Methods` lint pass

Move `BorrowAsPtr` into `Casts` lint pass

Move `AsUnderscore` into `Casts` lint pass

Better handle method/function calls

Add [`unused_peekable`] lint

Auto merge of #9295 - Guilherme-Vasconcelos:manual-empty-string-creation, r=dswij

Add `manual_empty_string_creations` lint

Closes #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()`

Auto merge of #9348 - lukaslueg:issue9347, r=Alexendoo

Don't lint on match pattern-binding in ´question_mark`

Fixes #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

Dont lint on match pattern-binding

Fixes #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.

Auto merge of #9136 - smoelius:enhance-needless-borrow, r=Jarcho

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

Auto merge of #9338 - sgued:9331-unwrap-err-used, r=giraffate

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 #9331

unwrap_used: Fix error message for unwrap_err when expect_used is allowed

Auto merge of #9287 - Jarcho:trans_undefined, r=xFrednet

`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

Rollup merge of #100018 - nnethercote:clean-up-LitKind, r=petrochenkov

Clean up `LitKind`

r? ``@petrochenkov``

Auto merge of #9345 - cherryblossom000:patch-1, r=flip1995

Fix typo in as_undescore docs

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: none

Auto merge of #9344 - Jarcho:opt_target_dir, r=flip1995

Handle `CARGO_TARGET_DIR` not being set in compile-test

changelog: None

Fix typo in as_undescore docs

du -> due

Handle `CARGO_TARGET_DIR` not being set in compile-test

Auto merge of #9341 - bmc-msft:suggest-map_or-instead-of-unwrap_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`.

Fix adjacent code

Enhance `needless_borrow` to consider trait implementations

Auto merge of #9343 - Serial-ATA:compiletest-target-env, r=Manishearth

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 :smile:.

Use `CARGO_TARGET_DIR` in compile-test

Auto merge of #9327 - Serial-ATA:non_ascii_literal_macro, r=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: #7739
closes: #8263

suggest map_or in case_sensitive_file_extension_comparisons

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.

Fix [`non_ascii_literal`] in tests

unwrap_used and expect_used: trigger on uses of their _err variants

Auto merge of #9340 - alex-semenyuk:box_t, r=dswij

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