See rust-lang#103308 (comment)
for this ask.

Only the android libunwind detection remains in the build script

* Reduces dependence on build scripts for building the standard library
* Reduces dependence on exact target names in favor of using semantic
  cfg(target_*) usage.
* Keeps almost all code related to linking of the unwinder in one file

This shows a small note on what the macro matcher was currently
processing to aid with "no rules expected the token X" errors.

…tifier

…=estebank

Show note where the macro failed to match

When feeding the wrong tokens, it used to fail with a very generic error that wasn't very helpful. This change tries to help by noting where specifically the matching went wrong.

```rust
macro_rules! uwu {
    (a a a b) => {};
}
uwu! { a a a c }
```

```diff
error: no rules expected the token `c`
 --> macros.rs:5:14
  |
1 | macro_rules! uwu {
  | ---------------- when calling this macro
...
4 | uwu! { a a a c }
  |              ^ no rules expected this token in macro call
  |
+note: while trying to match `b`
+ --> macros.rs:2:12
+  |
+2 |     (a a a b) => {};
+  |            ^
```

…ized, r=JohnTitor

Adjust stabilization version to 1.65.0 for wasi fds

See rust-lang#103308 (comment) for this ask.

Backport of that PR to beta (1.65.0) will include a similar patch.

Visit attributes of trait impl items during AST validation

Fixes rust-lang#104140.

This fix might not be backward compatible (in practice) since we now validate more attributes than before.
Should I write more tests?

`@rustbot` label A-attributes

…, r=Mark-Simulacrum

Move most of unwind's build script to lib.rs

Only the android libunwind detection remains in the build script

* Reduces dependence on build scripts for building the standard library
* Reduces dependence on exact target names in favor of using semantic cfg(target_*) usage.
* Keeps almost all code related to linking of the unwinder in one file

…e, r=oli-obk

Deduce closure signature from a type alias `impl Trait`'s supertraits

r? `@oli-obk`

Basically pass the TAIT's bounds through the same method that we're using to deduce a signature from infer var closure bounds.

Does this need a new FCP? I see it as a logical extension of rust-lang#101834, but happy to rfcbot a new one if it does.

…alization-cycle, r=lcnr

Walk types more carefully in `ProhibitOpaqueTypes` visitor

The visitor didn't account for the case where you could have `<TAIT as Trait>::Assoc` normalize to itself, in the case of a `type TAIT = impl Trait` with an unconstrained associated type. That causes the visitor to loop on the same type over and over.

Fixes rust-lang#104291

…ifier-error, r=davidtwco

Slightly improve error message for invalid identifier

fixes rust-lang#104088

…, r=estebank

Simplify suggestions for errors in generators.

Split from rust-lang#101692

…t_impl, r=cjgillot

Add `rustc_deny_explicit_impl`

Also adjust `E0322` error message to be more general, since it's used for `DiscriminantKind` and `Pointee` as well.

Also add `rustc_deny_explicit_impl` on the `Tuple` and `Destruct` marker traits.