This is desired for rust-lang#118702.

… MIR

There are cases where coverage instrumentation wants to show a span for some
syntax element, but there is no MIR node that naturally carries that span, so
the instrumentor can't see it.

MIR building can now use this new kind of coverage statement to deliberately
include those spans in MIR, attached to a dummy statement that has no other
effect.

This replaces the previous workaround, which was to inject a dummy `Assign`
statement.

When MIR is built for an if-not expression, the `!` part of the condition
doesn't correspond to any MIR statement, so coverage instrumentation normally
can't see it.

We can fix that by deliberately injecting a dummy statement whose sole purpose
is to associate that span with its enclosing block.

This should make it easier to investigate unwrap failures in bug reports.

LLVM commit llvm/llvm-project@e817966
renamed the `unaligned-scalar-mem` target feature to `fast-unaligned-access`.

according to a poll of gay people in my phone, purple is the most popular color to use for highlighting

| color      | percentage |
| ---------- | ---------- |
| bold white | 6%         |
| blue       | 14%        |
| cyan       | 26%        |
| purple     | 37%        |
| magenta    | 17%        |

unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason.
until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it.

instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty.

coverage: Use `SpanMarker` to improve coverage spans for `if !` expressions

Coverage instrumentation works by extracting source code spans from MIR. However, some kinds of syntax are effectively erased during MIR building, so their spans don't necessarily exist anywhere in MIR, making them invisible to the coverage instrumentor (unless we resort to various heuristics and hacks to recover them).

This PR introduces `CoverageKind::SpanMarker`, which is a new variant of `StatementKind::Coverage`. Its sole purpose is to represent spans that would otherwise not appear in MIR, so that the coverage instrumentor can extract them.

When coverage is enabled, the MIR builder can insert these dummy statements as needed, to improve the accuracy of spans used by coverage mappings.

Fixes rust-lang#115468.

---

``@rustbot`` label +A-code-coverage

…ted-tests, r=jackh726

Add tests related to normalization in implied bounds

Getting ``@aliemjay's`` tests from rust-lang#109763, so we can better track what's going on in every different example.

r? ``@jackh726``

update target feature following LLVM API change

LLVM commit llvm/llvm-project@e817966 renamed* the `unaligned-scalar-mem` target feature to `fast-unaligned-access`.

(*) technically the commit folded two previous features into one, but there are no references to the other one in rust.

coverage: Simplify the heuristic for ignoring `async fn` return spans

The code for extracting coverage spans from MIR has a special heuristic for dealing with `async fn`, so that the function's closing brace does not have a confusing double count.

The code implementing that heuristic is currently mixed in with the code for flushing remaining spans after the main refinement loop, making the refinement code harder to understand.

We can solve that by hoisting the heuristic to an earlier stage, after the spans have been extracted and sorted but before they have been processed by the refinement loop.

The coverage tests verify that the heuristic is still effective, so coverage mappings/reports for `async fn` have not changed.

---

This PR also has the side-effect of fixing the `None some_prev` panic that started appearing after rust-lang#118525.

The old code assumed that `prev` would always be present after the refinement loop. That was only true if the list of collected spans was non-empty, but prior to rust-lang#118525 that didn't seem to come up in practice. After that change, the list of collected spans could be empty in some specific circumstances, leading to panics.

The new code uses an `if let` to inspect `prev`, which correctly does nothing if there is no span present.

…estsa, r=Nilstrieb

Extend tidy alphabetical checking to `tests/`.

This is desired for rust-lang#118702.

r? ``@Nilstrieb``

use bold magenta instead of bold white for highlighting

according to a poll of gay people in my phone, purple is the most popular color to use for highlighting

| color      | percentage |
| ---------- | ---------- |
| bold white | 6%         |
| blue       | 14%        |
| cyan       | 26%        |
| purple     | 37%        |
| magenta    | 17%        |

unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason.
until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it.

instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty.

before:
![image](https://github.com/rust-lang/rust/assets/23638587/9a89eee2-8b89-422e-8554-812827bb2a23)

after:
![image](https://github.com/rust-lang/rust/assets/23638587/5bf3a917-8a20-4afd-af3e-f9491d0d57f5)

other colors for comparison:
blue: ![image](https://github.com/rust-lang/rust/assets/23638587/6f199c7b-d598-4009-8ffc-6b7b1d0d1f8c)
cyan: ![image](https://github.com/rust-lang/rust/assets/23638587/a77e4fe3-563e-4aa5-ae92-745bb67287d1)
purple: ![image](https://github.com/rust-lang/rust/assets/23638587/ffe603fb-d811-4106-95a9-4dd4c955924c)
magenta without bolding: ![image](https://github.com/rust-lang/rust/assets/23638587/cf927e5f-8b25-4dc2-b8e7-32905a11a459)

r? ``@estebank``

Some more minor `async gen`-related nits

Tiny tweaks found after `async gen` pr landed

r? eholk

…or, r=eholk

Make async generators fused by default

I actually changed my mind about this since the implementation PR landed. I think it's beneficial for `async gen` blocks to be "fused" by default -- i.e., for them to repeatedly return `Poll::Ready(None)` -- rather than panic.

We have [`FusedStream`](https://docs.rs/futures/latest/futures/stream/trait.FusedStream.html) in futures-rs to represent streams with this capability already anyways.

r? eholk
cc ``@rust-lang/wg-async,`` would like to know if anyone else has opinions about this.