First, this reverts the `CFLAGS`/`CXXFLAGS` of #93918. Those flags are
already read by `cc` and populated into `Build` earlier on in the
process. We shouldn't be overriding that based on `CFLAGS`, since `cc`
also respects overrides like `CFLAGS_{TARGET}` and `HOST_CFLAGS`, which
we want to take into account.

Second, this adds the same capability to specify target-specific
versions of `LDFLAGS` as we have through `cc` for the `C*` flags:
https://github.com/alexcrichton/cc-rs#external-configuration-via-environment-variables

Note that this also necessitated an update to compiletest to treat
CXXFLAGS separately from CFLAGS.

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`

Rollup of 8 pull requests

Successful merges:

 - #93562 (Update the documentation for `{As,Into,From}Raw{Fd,Handle,Socket}`.)
 - #94101 (rustdoc: add test cases for hidden enum variants)
 - #94484 (8 - Make more use of `let_chains`)
 - #94522 (Remove out-of-context line at end of E0284 message)
 - #94534 (Re-export (unstable) core::ffi types from std::ffi)
 - #94536 (Move transmute_undefined_repr back to nursery again)
 - #94537 (Use ? operator in one instance instead of manual match)
 - #94544 (Add some examples to comments in mbe code)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Add some examples to comments in mbe code

I found these things non-obvious when re-familiarizing myself with the code.

r? `@petrochenkov`

Use ? operator in one instance instead of manual match

As suggested [here](https://github.com/rust-lang/rust/pull/94139#discussion_r818102403).

r? `@notriddle`

Move transmute_undefined_repr back to nursery again

This PR reapplies #94014, which was reverted unintentionally I think by #94329. The combination of https://github.com/rust-lang/rust-clippy/pull/8432 + https://github.com/rust-lang/rust-clippy/pull/8497 in clippy should prevent this from happening again.

r? `@Manishearth`

Re-export (unstable) core::ffi types from std::ffi

Remove out-of-context line at end of E0284 message

Removed the last line of E0284 message because it was out of context (probably kept by accident when changing whole error message).

8 - Make more use of `let_chains`

Continuation of #94376.

cc #53667

rustdoc: add test cases for hidden enum variants

Update the documentation for `{As,Into,From}Raw{Fd,Handle,Socket}`.

This change weakens the descriptions of the
`{as,into,from}_raw_{fd,handle,socket}` descriptions from saying that
they *do* express ownership relations to say that they are *typically used*
in ways that express ownership relations. This is needed since, for
example, std's own [`RawFd`] implements `{As,From,Into}Fd` without any of
the ownership relationships.

This adds proper `# Safety` comments to `from_raw_{fd,handle,socket}`,
adds the requirement that raw handles be not opened with the
`FILE_FLAG_OVERLAPPED` flag, and merges the `OwnedHandle::from_raw_handle`
comment into the main `FromRawHandle::from_raw_handle` comment.

And, this changes `HandleOrNull` and `HandleOrInvalid` to not implement
`FromRawHandle`, since they are intended for limited use in FFI situations,
and not for generic use, and they have constraints that are stronger than
the those of `FromRawHandle`.

[`RawFd`]: https://doc.rust-lang.org/stable/std/os/unix/io/type.RawFd.html

Rollup of 9 pull requests

Successful merges:

 - #92061 (update char signess for openbsd)
 - #93072 (Compatible variants suggestion with desugaring)
 - #93354 (Add documentation about `BorrowedFd::to_owned`.)
 - #93663 (Rename `BorrowedFd::borrow_raw_fd` to `BorrowedFd::borrow_raw`.)
 - #94375 (Adt copy suggestions)
 - #94433 (Improve allowness of the unexpected_cfgs lint)
 - #94499 (Documentation was missed when demoting Windows XP to no_std only)
 - #94505 (Restore the local filter on mono item sorting)
 - #94529 (Unused doc comments blocks)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

There may eventually be something to say about `FILE_FLAG_OVERLAPPED` here,
however this appears to be independent of the other changes in this PR,
so remove them from this PR so that it can be discussed separately.

Unused doc comments blocks

Fixes #77030.

Restore the local filter on mono item sorting

In `CodegenUnit::items_in_deterministic_order`, there's a comment that
only local HirIds should be taken into account, but #90408 removed the
`as_local` call that sets others to None. Restoring that check fixes the
s390x hangs seen in [RHBZ 2058803].

[RHBZ 2058803]: https://bugzilla.redhat.com/show_bug.cgi?id=2058803

Documentation was missed when demoting Windows XP to no_std only

After a quick discussion on #81250 which removed special casing for mutexes added [here](https://github.com/rust-lang/rust/commit/10b103af48368c5df644fa61dc417a36083922c8) 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.

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 https://github.com/rust-lang/rust/pull/94298.
r? ````````@petrochenkov````````

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 #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 :')

Rename `BorrowedFd::borrow_raw_fd` to `BorrowedFd::borrow_raw`.

Also, rename `BorrowedHandle::borrow_raw_handle` and
`BorrowedSocket::borrow_raw_socket` to `BorrowedHandle::borrow_raw` and
`BorrowedSocket::borrow_raw`.

This is just a minor rename to reduce redundancy in the user code calling
these functions, and to eliminate an inessential difference between
`BorrowedFd` code and `BorrowedHandle`/`BorrowedSocket` code.

While here, add a simple test exercising `BorrowedFd::borrow_raw_fd`.

r? ``````@joshtriplett``````

Add documentation about `BorrowedFd::to_owned`.

Following up on #88564, this adds documentation explaining why
`BorrowedFd::to_owned` returns another `BorrowedFd` rather than an
`OwnedFd`. And similar for `BorrowedHandle` and `BorrowedSocket`.

r? `````@joshtriplett`````

Compatible variants suggestion with desugaring

This fixes #90553 for `for` loops and other desugarings.

r? ```@estebank```

update char signess for openbsd

it adds more archs support for openbsd: arm, mips64, powerpc, powerpc64, and riscv64.

There's still open discussion if this lint is ready to be enabled by
default. We want to give us more time to figure this out and prevent
this lint from getting to stable as an enabled-by-default lint.

Error if submodule fetch fails.

In CI, if fetching a submodule fails, the script would exit successfully. Later parts of the build will fail due to the missing files, but it is a bit confusing, and I think it would be better to error out earlier.

The reason is that in bash, `wait` without arguments will exit 0 even if a background job exits with an error. The solution here is to wait on each individual job, which will return the exit code of the job.

This was encountered in #92177.

Rename `ErrorReported` -> `ErrorGuaranteed`

r? `@EddyB`

cc https://github.com/rust-lang/rust/pull/93222 https://github.com/rust-lang/rust/issues/69426

The idea is that we would like to use it for both errors and `delay_span_bug`. Its semantics indicate a _guarantee_ that compilation will fail.