…o::metadata more generally applicable.

…accidentally been

removed in rust-lang#89597.

Also describe vtables as structs with a field for each entry.

…view comments

…ice, r=wesleywiser

Better suggestions when user tries to collect into an unsized `[_]`

1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note, label, etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases.
2. Add a `rustc_on_unimplemented` if we fail on `FromIterator<A> for [A]` which happens when we don't explicitly collect into a `vec<A>`, but then pass the return from a `.collect` call into something that takes a slice.

Fixes rust-lang#91423

`#[used(linker)]` attribute

See dtolnay/linkme#41 (comment).

…debuginfo-regression, r=wesleywiser

debuginfo: Fix DW_AT_containing_type vtable debuginfo regression

This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in rust-lang#89597.

It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable.

r? ``@wesleywiser``

This PR should fix issue rust-lang#93164.
~~The PR is blocked on rust-lang#93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~

…henkov

Complete removal of #[main] attribute from compiler

resolves rust-lang#93786

---

The `#[main]` attribute was mostly removed from the language in rust-lang#84217, but not completely. It is still recognized as a builtin attribute by the compiler, but it has no effect. However, this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists), so it's possible to include it in code *on stable* without any errors, which seems unintentional. For example, the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)).

```rust
#[main]
fn main() {
    println!("hello world");
}
```

Aside from that oddity, the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According rust-lang#84062 (comment), the removal of `#[main]` was expected to eliminate this conflict (previously reported as rust-lang#62127).

```rust
use tokio::main;

#[main]
fn main() {
    println!("hello world");
}
```

```
error[E0659]: `main` is ambiguous
 --> src/main.rs:3:3
  |
3 | #[main]
  |   ^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `main` could refer to a built-in attribute
```

[This error message can be confusing](https://stackoverflow.com/q/71024443/1114), as the mostly-removed `#[main]` attribute is not mentioned in any documentation.

Since the current availability of `#[main]` on stable seems unintentional, and to needlessly block use of the `main` identifier in the attribute namespace, this PR finishes removing the `#[main]` attribute as described in rust-lang#29634 (comment) by deleting it from `builtin_attrs.rs`, and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.

Fix typo in `std::fmt` docs

Hey!

Reading the docs (https://doc.rust-lang.org/std/fmt/#named-parameters), this seems like a typo?

The docs here also seem to mix “named argument” and “named parameter”? Intentional? Mistake?

…wiser

Make a few cleanup MIR passes public

Zulip Discussion: https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Making.20passes.20public.20again

This makes a few passes which used to be public, public again. I'd like to use these to clean up MIR code for my external rustc driver. The other option would be to make them all public, but I don't know if that's warranted / useful.

r? `@wesleywiser`