In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.

The checking variant ensures that the offset required is not larger than
12 bits - hence we wouldn't ever need the upper 12 bits.

…bited enum variant

…stebank

move implicit `Sized` predicate to end of list

In `Bounds::predicates()`, move the implicit `Sized` predicate to the
end of the generated list. This means that if there is an explicit
`Sized` bound, it will be checked first, and any resulting
diagnostics will have a more useful span.

Fixes rust-lang#85998, at least partially. ~~Based on rust-lang#85979, but only the last 2 commits are new for this pull request.~~ (edit: rebased) A full fix would need to deal with where-clauses, and that seems difficult. Basically, predicates are being collected in multiple stages, and there are two places where implicit `Sized` predicates can be inserted: once for generic parameters, and once for where-clauses. I think this insertion is happening too early, and we should actually do it only at points where we collect all of the relevant trait bounds for a type parameter.

I could use some help interpreting the changes to the stderr output. It looks like reordering the predicates changed some diagnostics that don't obviously have anything to do with `Sized` bounds. Possibly some error reporting code is making assumptions about ordering of predicates? The diagnostics for src/test/ui/derives/derives-span-Hash-*.rs seem to have improved, no longer pointing at the type parameter identifier, but src/test/ui/type-alias-impl-trait/generic_duplicate_param_use9.rs became less verbose for some reason.

I also ran into an instance of rust-lang#84970 while working on this, but I kind of expected that could happen, because I'm reordering predicates. I can open a separate issue on that if it would be helpful.

``@estebank`` this seems likely to conflict (slightly?) with your work on rust-lang#85947; how would you like to resolve that?

…ark-Simulacrum

Add a strange test for `unsafe_code` lint.

The current behavior is a little surprising to me. I'm not sure whether people would change it, but at least let me document the current behavior with a test.

I learnt about this from the [totally-speedy-transmute](https://docs.rs/totally-speedy-transmute) crate.

cc rust-lang#10599 the original implementation pr.

add dedicated error variant for writing the discriminant of an uninhabited enum variant

This is conceptually different from hitting an `Unreachable` terminator. Also add some sanity check making sure we don't write discriminants of things that do not have discriminants.

r? ``@oli-obk``

Suggest Box::pin when Pin::new is used instead

This fixes an incorrect diagnostic.

**Based on rust-lang#89390**; only the last commit is specific to this PR. "Ignore whitespace changes" also helps here.

…anieu

Use non-checking TLS relocation in aarch64 asm! sym test.

The checking variant ensures that the offset required is not larger than 12 bits - hence we wouldn't ever need the upper 12 bits.

It's unlikely to ever fail in this small test but this is technically correct.

This was noticed incidentally when we found that LLD doesn't support the `tprel_lo12` relocation, even though LLVM can apparently generate it when using `-mtls-size=12`.

… r=GuillaumeGomez

add long explanation for E0183

Addresses rust-lang#61137

…lacrum

Remove unused dependencies from rustc_const_eval