Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #110966

Closed
wants to merge 25 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 25 commits April 27, 2023 00:57
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.
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.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 28, 2023
@matthiaskrgr matthiaskrgr deleted the rollup-l6u5hfx branch March 16, 2024 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants