Support can be determined by checking for the "d32" LLVM feature.

Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.

Add `rustc_middle::ty::suggest_constraining_type_params` that suggests
adding multiple constraints.

`suggest_constraining_type_param` now just forwards params to this new
function.

Previously we've only suggested adding `Copy` bounds when the type being
moved/copied is a type parameter (generic). With this commit we also
suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type
  params

i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest
anything for `Option<String>`.

Future work: it would be nice to also suggest adding `.clone()` calls

Modify the tier 3 non-ARM targets to show the standard library will no longer build for these and there is no work being done to change that.

Do not point at whole file missing `fn main`

Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.

Ensure stability directives are checked in all cases

Split off  rust-lang#93017

Stability and deprecation were not checked in all cases, for instance if a type error happened.
This PR moves the check earlier in the pipeline to ensure the errors are emitted in all cases.

r? ```@lcnr```

ARM: Only allow using d16-d31 with asm! when supported by the target

Support can be determined by checking for the "d32" LLVM feature.

r? ````@nagisa````

…ebank

Adt copy suggestions

Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type params

i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest anything for `Option<String>`.

An example:
```rust
fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
    (t, t)
}
```
New error (current compiler doesn't provide `help`:):
```text
error[E0382]: use of moved value: `t`
 --> t.rs:2:9
  |
1 | fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
  |                 - move occurs because `t` has type `Option<T>`, which does not implement the `Copy` trait
2 |     (t, t)
  |      -  ^ value used here after move
  |      |
  |      value moved here
  |
help: consider restricting type parameter `T`
  |
1 | fn duplicate<T: Copy>(t: Option<T>) -> (Option<T>, Option<T>) {
  |               ++++++
```

Fixes rust-lang#93623
r? ````@estebank````
````@rustbot```` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement

----

I'm not at all sure if this is the right implementation for this kind of suggestion, but it seems to work :')

…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? `````@petrochenkov`````

Documentation was missed when demoting Windows XP to no_std only

After a quick discussion on rust-lang#81250 which removed special casing for mutexes added [here](rust-lang@10b103a) to support Windows XP, we can't say that the standard library can build for it.

This change modifies the tier 3 non-ARM targets to show the standard library will no longer build for these and there is no work being done to change that.

Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ```@oli-obk```