In obscure circumstances, we would sometimes emit a covfun record for a
function with no physical coverage counters, causing `llvm-cov` to fail with
the cryptic error message:

    malformed instrumentation profile data: function name is empty

We can eliminate this mismatch by removing `instances_used` entirely, and
instead inferring its contents from the keys of `pgo_func_name_var_map`.

This makes it impossible for a "used" function to lack a PGO name entry.

Rollup of 7 pull requests

Successful merges:

 - #144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs)
 - #144151 (`tests/ui/issues/`: The Issues Strike Back [1/N])
 - #144300 (Clippy fixes for miropt-test-tools)
 - #144399 (Add a ratchet for moving all standard library tests to separate packages)
 - #144472 (str: Mark unstable `round_char_boundary` feature functions as const)
 - #144503 (Various refactors to the codegen coordinator code (part 3))
 - #144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #144530 - Zalathar:instances-used, r=lqd

coverage: Infer `instances_used` from `pgo_func_name_var_map`

In obscure circumstances involving macro-expanded spans, we would sometimes emit a covfun record for a function with no physical coverage counters, and therefore no corresponding entry in the “PGO names” section of the binary. The absence of that name entry causes `llvm-cov` to fail with the cryptic error message:

```text
malformed instrumentation profile data: function name is empty
```

We can eliminate this mismatch by removing `instances_used` entirely, and instead inferring its contents from the keys of `pgo_func_name_var_map`.

This makes it impossible for a "used" function to lack a PGO name entry.

---

This is an attempt to eliminate the cause of #141577 when re-landing changes like #144298 in the future.

I haven't been able to reproduce the underlying issue in an in-tree test, because the only known repro involves a non-trivial derive proc-macro that relies on `syn` and `proc-macro2`. But I have manually verified in a separate branch that this change would have prevented the reoccurrence of #141577 (comment).

Rollup merge of #144616 - Zalathar:try-in-macro, r=jieyouxu

coverage: Regression test for "function name is empty" bug

Regression test for #141577, which was triggered by #144298.

The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion.

Thanks to lqd for the minimization at #144571 (comment).

---

I have manually verified that reverting the relevant follow-up fixes (#144480 and #144530) causes this test to reproduce the bug:

```sh
git revert -m1 8aa3d41 c462895
```

---

r? compiler

coverage: Re-land "Enlarge empty spans during MIR instrumentation"

This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.

---

This seemingly-simple change has a rather messy history:
- rust-lang#140847
- rust-lang#141650
- rust-lang#144298
- rust-lang#144480

Since then, a number of related changes have landed that should make it reasonable to try again:
- rust-lang#144530
- rust-lang#144560
- rust-lang#144616

In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.

coverage: Regression test for "function name is empty" bug

Regression test for rust-lang/rust#141577, which was triggered by rust-lang/rust#144298.

The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion.

Thanks to lqd for the minimization at rust-lang/rust#144571 (comment).

---

I have manually verified that reverting the relevant follow-up fixes (rust-lang/rust#144480 and rust-lang/rust#144530) causes this test to reproduce the bug:

```sh
git revert -m1 8aa3d41b8527f9f78e0f2459b50a6e13aea35144 c462895a6f0b463ff0c1c1db2a3a654d7e5976c7
```

---

r? compiler

coverage: Re-land "Enlarge empty spans during MIR instrumentation"

This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.

---

This seemingly-simple change has a rather messy history:
- rust-lang#140847
- rust-lang#141650
- rust-lang#144298
- rust-lang#144480

Since then, a number of related changes have landed that should make it reasonable to try again:
- rust-lang#144530
- rust-lang#144560
- rust-lang#144616

In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.

Rollup merge of #144663 - Zalathar:empty-span, r=petrochenkov

coverage: Re-land "Enlarge empty spans during MIR instrumentation"

This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.

---

This seemingly-simple change has a rather messy history:
- #140847
- #141650
- #144298
- #144480

Since then, a number of related changes have landed that should make it reasonable to try again:
- #144530
- #144560
- #144616

In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.