…-cov`

Removing opener 0.5.2, and updating cargo_metadata 0.15.4 -> cargo_metadata 0.18.0

Reverting rustfmt change

Reverting rustfmt patch

Reverting dependency change for clippy

rc,sync: Do not create references to uninitialized values

Closes rust-lang#119241

r? `@RalfJung`

…wiser

coverage: Never emit improperly-ordered coverage regions

If we emit a coverage region that is improperly ordered (end < start), `llvm-cov` will fail with `coveragemap_error::malformed`, which is inconvenient for users and also very hard to debug.

Ideally we would fix the root causes of these situations, but they tend to occur in very obscure edge-case scenarios (often involving nested macros), and we don't always have a good MCVE to work from. So it makes sense to also have a catch-all check that will prevent improperly-ordered regions from ever being emitted.

---

This is mainly aimed at resolving rust-lang#119453. We don't have a specific way to reproduce it, which is why I haven't been able to add a test case in this PR. But based on the information provided in that issue, this change seems likely to avoid the error in `llvm-cov`.

`@rustbot` label +A-code-coverage

…mpiler-errors

Split tait and impl trait in assoc items logic

And simplify the assoc item logic where applicable.

This separation shows that it is easier to reason about impl trait in assoc items compared with TAITs. See https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/impl.20trait.20in.20associated.20type for some discussion.

The current plan is to try to stabilize impl trait in associated items before TAIT, as they do not have any issues with their defining scopes (see rust-lang#107645 for why this is not a trivial or uncontroversial topic).

…lnay

Manually implement derived `NonZero` traits.

Step 3 as mentioned in rust-lang#100428 (review).

Manually implement the traits that would cause “borrow of layout constrained field with interior mutability” errors when switching to `NonZero<T>`.

r? `@dtolnay`

…trieb

Remove duplicate dependencies for rustc

Removed several duplicates for rustc: rust-lang#75704

Several duplicates still exist, but an external library would have to be updated first.

These are the duplicate dependencies still outstanding:
```
annotate-snippets v0.9.1
annotate-snippets v0.10.1

bitflags v1.3.2
bitflags v2.4.1

cargo_metadata v0.15.4
cargo_metadata v0.18.0

darling v0.14.4
darling v0.20.3

darling_core v0.14.4
darling_core v0.20.3

darling_macro v0.14.4
darling_macro v0.20.3

regex-automata v0.1.10
regex-automata v0.2.0
regex-automata v0.4.3

regex-syntax v0.6.29
regex-syntax v0.7.2
regex-syntax v0.8.2

self_cell v0.10.3
self_cell v1.0.2

syn v1.0.109
syn v2.0.32

toml v0.5.11
toml v0.7.5
```

It should not be hard to consolidate these remaining duplicate dependencies, but it will take time as it would be pull requests for external crates.

r? `@jyn514`

…errors

Add `#[coverage(off)]` to closures introduced by `#[test]` and `#[bench]`

These closures are an internal implementation detail of the `#[test]` and `#[bench]` attribute macros, so from a user perspective there is no reason to instrument them for coverage.

Skipping them makes coverage reports slightly cleaner, and will also allow other changes to span processing during coverage instrumentation, without having to worry about how they affect the `#[test]` macro.

The `#[coverage(off)]` attribute has no effect when `-Cinstrument-coverage` is not used.

Fixes rust-lang#120046.

---

Note that this PR has no effect on the user-written function that has the `#[test]` attribute attached to it. That function will still be instrumented as normal.

coverage: Don't instrument `#[automatically_derived]` functions

This PR makes the coverage instrumentor detect and skip functions that have [`#[automatically_derived]`](https://doc.rust-lang.org/reference/attributes/derive.html#the-automatically_derived-attribute) on their enclosing impl block.

Most notably, this means that methods generated by built-in derives (e.g. `Clone`, `Debug`, `PartialEq`) are now ignored by coverage instrumentation, and won't appear as executed or not-executed in coverage reports.

This is a noticeable change in user-visible behaviour, but overall I think it's a net improvement. For example, we've had a few user requests for this sort of change (e.g. rust-lang#105055, rust-lang#84605 (comment)), and I believe it's the behaviour that most users will expect/prefer by default.

It's possible to imagine situations where users would want to instrument these derived implementations, but I think it's OK to treat that as an opportunity to consider adding more fine-grained option flags to control the details of coverage instrumentation, while leaving this new behaviour as the default.

(Also note that while `-Cinstrument-coverage` is a stable feature, the exact details of coverage instrumentation are allowed to change. So we *can* make this change; the main question is whether we *should*.)

Fixes rust-lang#105055.

Bump some deps with syn 1.0 dependencies

cc rust-lang#109302

`cargo update`ing `unic-langid` and `object` removes two dependencies on Syn 1.0.

…estebank

Re-add estebank to review rotation

r? `@compiler-errors`