Rollup of 11 pull requests - #163415
Closed
jhpratt wants to merge 38 commits into
Closed
Rollup of 11 pull requests#163415jhpratt wants to merge 38 commits into
jhpratt wants to merge 38 commits into
Conversation
Instead of hardcoding the container layout assuming that the local patches are in /build, look for them next to the script. This helps downstream distros to run this script if their container layout is different and they don't put the musl working dir in /build. This might be an unexpected change for some dowstream distros that were using this script from another directory,but arranged for the patches to still be in `/build`
It's a cut down version of `rustc_errors::DiagInner` that avoids `Span`. It exists because `Span` used to not impl `Send` and so couldn't be sent from codegen threads to the main thread. But that's no longer true and we can send `DiagInner`s directly now.
By just storing `lo` and `hi` instead.
This whole section of the code deals with constructing an alternative layout, but large nesting makes the control flow seem more complex than it actually is.
Constructing these error variants is basically free
Having the generic list span multiple lines is quite jarring, and imo easy to confuse with the parameter list at a glance.
Improves consistency, and hopefully clarifies the purpose of previously-mysteriosly named methods like `univariant`.
Rustc already defaults to this for regular items whenever possible. Overriding it would only lead to linker errors. And for depending on the exact codegen unit partitioning rustc uses, so there it is a bad idea to use it too.
* Implement Default for NumBuffer * Make insta-stable
Rustc already defaults to this for #[no_mangle]/#[export_name] items. There is no reason to explicitly use it.
A common definition is like a weak definition except that it must be a zero-initialized static and when merging two common symbols with the same name, the size and alignment are set to the higher of both symbols. This is used for tentative definitions in C and doesn't have any reason to exist outside of that. This behavior doesn't work across dylibs and common symbols have inconsistent behavior across linkers [1]. It is also fragile to rely on getting the largest size of all common symbol definitions as a (possibly smaller) global definition can override it. Link: https://maskray.me/blog/all-about-common-symbols [1]
The name makes some sense at the callsite, but inside the function, the parameter refers to the `VariantIdx` that should be use for the newly-created layout, so name accordingly. Also move closer to the related `variants` param (Note: could consider passing `variants[present_first]` instead of `variants`, as that's the only way `variants` is used -- at the same type, passing `variants` seems more consistent with the rest of the file.)
This is a more type-safe alternative for the `niche_optimizations: bool` param
…t-module-typos, r=petrochenkov Suggest similarly named modules in import paths Fixes rust-lang#131366 The [last commit](rust-lang@cac7b61) is a seperated issue which fixed by the way.
[debugger visualizers] Add workaround to read `Rc` strong/weak counts Implements a fix with the same goal as rust-lang#162725 of removing the infinite loop. Since `RcInner` is `#[repr(C)]`, we can just directly read the values from their known offsets. Worth noting that LLDB fails to even populate the fields and offsets when this bug occurs, so `#[repr(C)]` is a required invariant to retrieve the values from addresses like this: ``` (lldb) script lldb.frame.var("holder").GetNonSyntheticValue().GetChildAtIndex(0).GetChildAtIndex(0).GetChildAtIndex(0).GetType().GetPointeeType() template<> struct RcInner<unsigned int> { private: unsigned int value; } ``` That `RcInner` should have a `strong` and `weak` field, but because LLDB can't read the type node, it omits them entirely. Thankfully, the `value` field is still read correctly and has an accurate offset. This change has 1 small side effect, which is that the `weak` count is not decremented before it is displayed to the user. We can easily do that in the summary function, but imo it feels weird to lie about the value in memory? The `weak` count starts at 1 because the original `Rc` instance "holds" both a strong and a weak reference. It's mostly an artifact of `Rc`'s implementation, but if you're debugging, that seems like something that might matter.
…yout, r=Mark-Simulacrum ci: make musl.sh look for patches next to the script Instead of hardcoding the container layout assuming that the local patches are in `/build`, look for them next to the script. This helps downstream distros to run this script if their container layout is different and they don't put the musl working dir in `/build`. This might be an unexpected change for some downstream distros that were using this script from another directory,but arranged for the patches to still be in `/build`
Remove some #[linkage] options These are either useless due to rustc already setting them whenever you would want them, actively breaking compiler invariants or both. cc rust-lang#29603 (comment)
…r=JonathanBrouwer mailmap: add Matilde Morrone Adds myself to the mailmap
Member
Author
|
@bors r+ p=5 force |
Contributor
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 28, 2026
Rollup of 11 pull requests Successful merges: - #163085 (Suggest similarly named modules in import paths) - #163098 ([debugger visualizers] Add workaround to read `Rc` strong/weak counts) - #163120 (ci: make musl.sh look for patches next to the script) - #163301 (Fix unused_must_use for scenario which may need to keep value) - #163307 (Less `SpanData` in diagnostics) - #152972 (implement PartialEq<VecDeque<U>> for Vec<T>, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]) - #162536 (Implement Default for NumBuffer) - #163141 (Document safety requirements for intrinsic fallbacks) - #163384 (Various clean-ups around `LayoutCalculator`) - #163405 (Remove some #[linkage] options) - #163413 (mailmap: add Matilde Morrone)
This comment has been minimized.
This comment has been minimized.
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for 0c69304 failed: CI. Failed job:
|
Contributor
|
PR #163405, which is a member of this rollup, was unapproved. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
Rcstrong/weak counts #163098 ([debugger visualizers] Add workaround to readRcstrong/weak counts)SpanDatain diagnostics #163307 (LessSpanDatain diagnostics)LayoutCalculator#163384 (Various clean-ups aroundLayoutCalculator)r? @ghost
Create a similar rollup