Replace #[rustc_do_not_implement_via_object] with #[rustc_dyn_incompatible_trait]

[zachs18]

May fix #148615

This affects three groups of traits:

1. MetaSized
   1. Removed #[rustc_do_not_implement_via_object]. Still dyn-compatible after this change. See question 1 below
2. PointeeSized
   1. Removed #[rustc_do_not_implement_via_object]. It doesn't seem to have been doing anything anyway (playground), since PointeeSized is removed before trait solving(?).
3. All the other traits which are currently #[rustc_do_not_implement_via_object] (including Pointee, Tuple, Destruct, etc)
   1. These traits now have #[rustc_dyn_incompatible_trait] and are now dyn-incompatible.

Questions before merge:

1. dyn MetaSized: MetaSized having both SizedCandidate and ObjectCandidate
   1. I'm not sure if the checks in compiler/rustc_trait_selection/src/traits/project.rs and compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs were "load-bearing" for MetaSized (which is the only trait that was previously #[rustc_do_not_implement_via_object] that is still dyn-compatible after this change). Is it fine to just remove them? Removing them (as I did in the second commit) doesn't change any UI test results.
   2. IIUC, dyn MetaSized could get its MetaSized implementation in two ways: the object candidate (the normal dyn Trait: Trait) that was supressed by #[rustc_do_not_implement_via_object], and the SizedCandidate (that all dyn Trait get for dyn Trait: MetaSized). Given that MetaSized has no associated types or methods, is it fine that these both exist now? Or is it better to only have the SizedCandidate and leave these checks in (i.e. drop the second commit, and remove the FIXMEs)?
2. Diagnostics improvements?
   1. The diagnostics are kinda bad. If you have a trait Foo: Pointee {}, you now get a note that reads like Foo "opted out of dyn-compatbility", when really Pointee did that.
3. compiler/rustc_hir/src/attrs/encode_cross_crate.rs: Should DynIncompatibleTrait attribute be encoded cross crate? I'm not sure what this actually does.

diagnostic example

#![feature(ptr_metadata)]

trait C: std::ptr::Pointee {}

fn main() {
    let y: &dyn C;
}

error[E0038]: the trait `C` is not dyn compatible
  --> c.rs:6:17
   |
 6 |     let y: &dyn C;
   |                 ^ `C` is not dyn compatible
   |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
  --> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/ptr/metadata.rs:57:1
   |
57 | #[rustc_dyn_incompatible_trait]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...because it opted out of dyn-compatbility
   |
  ::: c.rs:3:7
   |
 3 | trait C: std::ptr::Pointee {}
   |       - this trait is not dyn compatible...

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0038`.

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[nnethercote]

I know it says "DO NOT MERGE YET". Is it ready for review? If not, can you convert it to a draft PR?

Also, you might as well squash the tidy commits, there's no need for them to be separate.

[zachs18]

I know it says "DO NOT MERGE YET". Is it ready for review?

Yes, it is ready for review. I added that because I have questions in the PR description that should be addressed (and the commits amended based on the answers) before merging.

[theemathas]

Making Destruct be dyn-incompatible seems iffy to me...

[bors]

☔ The latest upstream changes (presumably #148753) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nnethercote]

This PR is really out of my wheelhouse. @compiler-errors reviewed a precursor (#134573) but I don't know if he's reviewing PRs right now, so...

r? compiler

[compiler-errors]

r? types probably is a better assignment