Fixes rust-lang#110912

Checking `flavor == RlibFlavor::Normal` was accidentally lost in
601fc8b
rust-lang#105601

That caused combining +whole-archive and +bundle link modifiers on
non-rlib crates to fail with a confusing error message saying that
combination is unstable for rlibs. In particular, this caused the
build to fail when +whole-archive was used on staticlib crates, even
though +whole-archive effectively does nothing on non-bin crates because
the final linker invocation is left to an external build system.

It's unnecessary. Note that `MemDecoder::read_raw_bytes` how has a `&'a
[u8]` return type, the same as what `read_raw_bytes_inherent` had.

Because I was wondering about it, and this may save a future person from
also wondering.

`rustc_arena`.

Checking that `read_raw_bytes(len)` changes the position by `len` is a
reasonable thing for a test, but isn't much use in just one of the
zillion `Decodable` impls.

The methods for `i8`, `bool`, `char`, `str` are the same for all impls,
because they layered on top of other methods.

It's just a synonym for `read_u8`.

I was curious about how many `Encodable`/`Decodable` derives we have.
Some grepping revealed that it's over 500 of each, but the number of
`Encodable` ones was higher, which was weird. Most of the
`Encodable`-only ones were in `hir.rs`. This commit removes them all,
plus some other unnecessary derives in that file and others that I found
via trial and error.

Provide better type hints when a type doesn't support a binary operator

For example, when checking whether `vec![A] == vec![A]` holds, we first evaluate the LHS's ty, then probe for any `PartialEq` implementations for that. If none is found, we report an error by evaluating `Vec<A>: PartialEq<?0>` for fulfillment errors, but the RHS is not yet evaluated and remains an inference variable `?0`!

To fix this, we evaluate the RHS and equate it to that RHS infer var `?0`, so that we are able to provide more detailed fulfillment errors for why `Vec<A>: PartialEq<Vec<A>>` doesn't hold (namely, the nested obligation `A: PartialEq<A>` doesn't hold).

Fixes rust-lang#95285
Fixes rust-lang#110867

…b_fix, r=petrochenkov

only error combining +whole-archive and +bundle for rlibs

Fixes rust-lang#110912

Checking `flavor == RlibFlavor::Normal` was accidentally lost in 601fc8b
rust-lang#105601

That caused combining +whole-archive and +bundle link modifiers on non-rlib crates to fail with a confusing error message saying that combination is unstable for rlibs. In particular, this caused the build to fail when +whole-archive was used on staticlib crates, even though +whole-archive effectively does nothing on non-bin crates because the final linker invocation is left to an external build system.

cc ``@petrochenkov``

…=Nilstrieb

Use `NonNull::new_unchecked` and `NonNull::len` in `rustc_arena`.

This avoids a few extra dereferences as well as an `unwrap`.

According to the docs for [`NonNull::len`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.len) this also ensures that:

> This function is safe, even when the non-null raw slice cannot be dereferenced to a slice because the pointer does not have a valid address.

I am also fairly sure that the `unwrap` is unneeded in this case, as the docs for [`Box::into_raw`](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.into_raw) also state:

> Consumes the Box, returning a wrapped raw pointer.
**The pointer will be properly aligned and non-null.**

…ps, r=scottmcm

Encoder/decoder cleanups

Best reviewed one commit at a time.

r? ``@scottmcm``

share BinOp::Offset between CTFE and Miri

r? ``@oli-obk``

run-make test: using single quotes to not trigger the shell

This test got added in rust-lang#110801.

I'm no expert on Makefiles, but IIUC this command is passed to the shell, which usually tries to execute commands specified in between backticks in double-quoted strings.

Using single quotes should fix this, I think. (Note: Waiting for CI to test this, since I only have a web browser available right now).

r? ``@jyn514``

cc ``@WaffleLapkin``

Since this is breaking our build bot, even if it is not directly LLVM related: ``@rustbot`` label: +llvm-main

…ict_error, r=cjgillot

Fix an ICE in conflict error diagnostics

Fixes  rust-lang#110929
r? ``@cjgillot``

…errors

fix false negative for `unused_mut`

fixes rust-lang#110849

We want to avoid double diagnostics for code like this, but only if an error actually occurs:
```rust
fn main() {
    let mut x: (i32, i32);
    x.0 = 1;
}
```

The first commit fixes the lint and the second one removes all the unused `mut`s it found.