It turns out the stars did not actually align for this to get released
in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two
PRs:

* rust-lang#126967 - this made it into Rust 1.81
* rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead

This wasn't caught until just after today's release so the plan is to
remove the release notes for 1.81 and coordinate to instead add these as
release notes to 1.82.

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. A future commit will
fix this and update the test to reflect the new behavior.

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.

… r=lcnr

Check WF of source type's signature on fn pointer cast

This PR patches the implied bounds holes slightly for rust-lang#129005, rust-lang#25860.

Like most implied bounds related unsoundness fixes, this isn't complete w.r.t. higher-ranked function signatures, but I believe it implements a pretty good heuristic for now.

### What does this do?

This PR makes a partial patch for a soundness hole in a `FnDef` -> `FnPtr` "reifying" pointer cast where we were never checking that the signature we are casting *from* is actually well-formed. Because of this, and because `FnDef` doesn't require its signature to be well-formed (just its predicates must hold), we are essentially allowed to "cast away" implied bounds that are assumed within the body of the `FnDef`:

```
fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'short, T>(x: &'short T) -> &'static T {
    let f: fn(_, &'short T) -> &'static T = foo;
    f(&&(), x)
}
```

In this example, subtyping ends up casting the `_` type (which should be `&'static &'short ()`) to some other type that no longer serves as a "witness" to the lifetime relationship `'short: 'static` which would otherwise be required for this call to be WF. This happens regardless of if `foo`'s lifetimes are early- or late-bound.

This PR implements two checks:
1. We check that the signature of the `FnDef` is well-formed *before* casting it. This ensures that there is at least one point in the MIR where we ensure that the `FnDef`'s implied bounds are actually satisfied by the caller.
2. Implements a special case where if we're casting from a higher-ranked `FnDef` to a non-higher-ranked, we instantiate the binder of the `FnDef` with *infer vars* and ensure that it is a supertype of the target of the cast.

The (2.) is necessary to validate that these pointer casts are valid for higher-ranked `FnDef`. Otherwise, the example above would still pass even if `help`'s `'a` lifetime were late-bound.

### Further work

The WF checks for function calls are scattered all over the MIR. We check the WF of args in call terminators, we check the WF of `FnDef` when we create a `const` operand referencing it, and we check the WF of the return type in rust-lang#115538, to name a few.

One way to make this a bit cleaner is to simply extend rust-lang#115538 to always check that the signature is WF for `FnDef` types. I may do this as a follow-up, but I wanted to keep this simple since this leads to some pretty bad NLL diagnostics regressions, and AFAICT this solution is *complete enough*.

### Crater triage

Done here: rust-lang#129021 (comment)

r? lcnr

… r=albertlarsan68

Make `./x.py <cmd> compiler/<crate>` aware of the crate's features

Does not fix rust-lang#129727 on its own as the way the parallel-compiler cfg and feature flags are setup being generally incompatible with `resolver = 2` but it progresses on the issue. But this should in theory allow compiler crates to work that do not depend on the parallel compiler stuff (so some leaf crates).

…ossy_doc, r=workingjubilee

Inaccurate `{Path,OsStr}::to_string_lossy()` documentation

The documentation of `Path::to_string_lossy()` and `OsStr::to_string_lossy()` says the following:
> Any non-Unicode sequences are replaced with `U+FFFD REPLACEMENT CHARACTER`

which didn't immediately make sense to me. ("non-Unicode sequences"?)
Since both `to_string_lossy` functions eventually become just a call to `String::from_utf8_lossy`, I believe the documentation meant to say:
> Any *non-UTF-8* sequences are replaced with `U+FFFD REPLACEMENT CHARACTER`

This PR corrects this mistake in the documentation.

For the record, a similar quote can be found in the documentation of `String::from_utf8_lossy`:
> ... During this conversion, `from_utf8_lossy()` will replace any invalid UTF-8 sequences with `U+FFFD REPLACEMENT CHARACTER`, ...

…errors

Make `Ty::boxed_ty` return an `Option`

Looks like a good place to use Rust's type system.

---

Most of https://github.com/rust-lang/rust/blob/4ac7bcbaad8d6fd7a51bdf1b696cbc3ba4c796cf/compiler/rustc_middle/src/ty/sty.rs#L971-L1963 looks like it could be moved to `TyKind` (then I guess  `Ty` should be made to deref to `TyKind`).

…release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for `wasm32-wasip2` required two PRs:

* rust-lang#126967 - this made it into Rust 1.81
* rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

…Zalathar

coverage: Count await when the Future is immediately ready

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.

I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.

closes rust-lang#98712