-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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 4 pull requests #131111
Rollup of 4 pull requests #131111
Conversation
MCP: rust-lang/compiler-team#782 Co-authored-by: bjorn3 <[email protected]>
… r=Urgau Replace -Z default-hidden-visibility with -Z default-visibility Issue rust-lang#105518
…ottmcm ptr::add/sub: do not claim equivalence with `offset(c as isize)` In rust-lang#110837, the `offset` intrinsic got changed to also allow a `usize` offset parameter. The intention is that this will do an unsigned multiplication with the size, and we have UB if that overflows -- and we also have UB if the result is larger than `usize::MAX`, i.e., if a subsequent cast to `isize` would wrap. ~~The LLVM backend sets some attributes accordingly.~~ This updates the docs for `add`/`sub` to match that intent, in preparation for adjusting codegen to exploit this UB. We use this opportunity to clarify what the exact requirements are: we compute the offset using mathematical multiplication (so it's no problem to have an `isize * usize` multiplication, we just multiply integers), and the result must fit in an `isize`. Cc `@rust-lang/opsem` `@nikic` rust-lang#130239 updates Miri to detect this UB. `sub` still has some cases of UB not reflected in the underlying intrinsic semantics (and Miri does not catch): when we subtract `usize::MAX`, then after casting to `isize` that's just `-1` so we end up adding one unit without noticing any UB, but actually the offset we gave does not fit in an `isize`. Miri will currently still not complain for such cases: ```rust fn main() { let x = &[0i32; 2]; let x = x.as_ptr(); // This should be UB, we are subtracting way too much. unsafe { x.sub(usize::MAX).read() }; } ``` However, the LLVM IR we generate here also is UB-free. This is "just" library UB but not language UB. Cc `@saethlin;` might be worth adding precondition checks against overflow on `offset`/`add`/`sub`? Fixes rust-lang#130211
Update Unicode escapes in `/library/core/src/char/methods.rs` `char::MAX` is inconsistent on how Unicode escapes should be formatted. This PR resolves that.
…aumeGomez,notriddle rustdoc: lists items that contain multiple paragraphs are more clear fixes rust-lang#130622 before: ![before](https:/user-attachments/assets/fe54d8ee-8a1a-45fc-9434-2737c5c6f4d5) after: ![after](https:/user-attachments/assets/095be365-1bfc-4001-8664-59bc4125bb05)
@bors r+ rollup=never p=4 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: c817d5dc20 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (06bb836): comparison URL. Overall result: ❌ regressions - 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)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: 771.522s -> 770.255s (-0.16%) |
It seems like #130005 would be the only PR that could possibly have introduced any perf variation here though it's not clear to me why. @rust-timer build b6a6fdc |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (b6a6fdc): comparison URL. Overall result: ❌ regressions - please read the text belowInstruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 4.5%)This 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.
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: 771.522s -> 769.405s (-0.27%) |
@rylev I believe it's because the PR introduced new unconditional query calls to compute the symbol visibility (even though it will still return the same default as before, until the default is switched to "protected" in the future). The big That is, we could gain the perf back, and delay this computation until that change is needed, most likely when lld is used on stable by default, so not right around the corner. |
cc @davidlattimore @Urgau (author and reviewer of #130005) for visibility ^^ |
Yeah, we may want to re-add the fast path for rust/compiler/rustc_monomorphize/src/partitioning.rs Lines 916 to 920 in 0999b01
|
The query will be more costly than the |
Oh, yeah you're right, when the default visibility wasn't changed we just returned rust/compiler/rustc_monomorphize/src/partitioning.rs Lines 906 to 909 in 0999b01
I completely overlook that. |
Add fast-path when computing the default visibility This PR adds (or more correctly re-adds the) fast-path when computing the default visibility, by taking advantage of the fact that the "interposable" requested visibility always return the "default" codegen visibility. Should address the small regression observed in rust-lang#131111 (comment). r? `@lqd`
Successful merges:
offset(c as isize)
#130229 (ptr::add/sub: do not claim equivalence withoffset(c as isize)
)/library/core/src/char/methods.rs
#130773 (Update Unicode escapes in/library/core/src/char/methods.rs
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup