-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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 #110967
Rollup of 8 pull requests #110967
Conversation
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.
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: f495605381 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (7a96158): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
I think there's a bit of noise here, but e.g. The wall-time on So maybe some of the cleanups in #110877 could be related, doing slightly more work than before: On
|
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (068e587367fa4e424eca954201fb0b90e2e4e8de): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 660.129s -> 659.944s (-0.03%) |
#110877 looks involved in some of these, so let's at least let author @compiler-errors know. |
I have absolutely no idea how that PR could've caused regressions. It hardly touches non-diagnostic code, let alone hot code 😅 |
It could indeed just be some unlucky rejuggling of the folding and predicates codegen. Looking at it wrong, or even just thinking about it, is apparently enough for it to become unstable in benchmarks (just typing this sentence has probably jinxed us with more instability). |
Successful merges:
NonNull::new_unchecked
andNonNull::len
inrustc_arena
. #110921 (UseNonNull::new_unchecked
andNonNull::len
inrustc_arena
.)unused_mut
#110960 (fix false negative forunused_mut
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup