-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 5 pull requests #111984
Rollup of 5 pull requests #111984
Conversation
It is small and has a single call site, and this change will facilitate the next commit.
Three of the four methods in `DefaultPartitioning` are defined in `default.rs`. But `merge_codegen_units` is defined in a separate module, `merging`, even though it's less than 100 lines of code and roughly the same size as the other three methods. (Also, the `merging` module currently sits alongside `default`, when it should be a submodule of `default`, adding to the confusion.) In rust-lang#74275 this explanation was given: > I pulled this out into a separate module since it seemed like we might > want a few different merge algorithms to choose from. But in the three years since there have been no additional merging algorithms, and there is no mechanism for choosing between different merging algorithms. (There is a mechanism, `-Zcgu-partitioning-strategy`, for choosing between different partitioning strategies, but the merging algorithm is just one piece of a partitioning strategy.) This commit merges `merging` into `default`, making the code easier to navigate and read.
I find that these structs obfuscate the code. Removing them and just passing the individual fields around makes the `Partition` method signatures a little longer, but makes the data flow much clearer. E.g. - `codegen_units` is mutable all the way through. - `codegen_units`'s length is changed by `merge_codegen_units`, but only the individual elements are changed by `place_inlined_mono_items` and `internalize_symbols`. - `roots`, `internalization_candidates`, and `mono_item_placements` are all immutable after creation, and all used by just one of the four methods.
This is something that took me some time to figure out.
Issue rust-lang#106021 Apple LD requires build versions in object files for Catalyst
As per review request.
…henkov Fix linking Mac Catalyst by including LC_BUILD_VERSION in object files Hello. My first rustc PR! Issue rust-lang#106021 prevents Rust code from being linked into Mac Catalyst applications. Apple's LD has started requiring object files to contain version information about the platform they were built for, such as: * the "deployment target" (minimum supported OS version), * the SDK version * the type of the platform (macOS/iOS/catalyst/tvOS/watchOS all have a different number). This is currently only enforced when building for Mac Catalyst. Rust uses the `object` crate which added support for including this information starting with `0.31.0`. ~~I upgraded it along with `thorin-dwp` so that everything depends on 0.31. Apparently 0.31 [pulls in](gimli-rs/object#463) `ruzstd` due to a [new ELF standard](https://maskray.me/blog/2022-09-09-zstd-compressed-debug-sections) because its `compression` feature is enabled by thorin. If you find this objectionable, let me know what the best way to avoid pulling in those dependencies might be.~~ **(`object` upgraded in rust-lang#111413 I then added two commits: * The first one adds very basic, hard-coded support for calling `set_macho_build_version` for `-macabi` (Catalyst) targets, where it claims deployment target of Catalyst 14.0 and SDK of 16.2. * The second weaves the versioning through `rust_target::spec::TargetOptions`, so that we can stick to specifying all target-related info in one place. Kudos to ``@ara4n`` for writing [this gist](https://gist.github.com/ara4n/320a53ea768aba51afad4c9ed2168536).
…wiser CGU cleanups Some code clarity improvements I found when reading this code closely. r? ``@wesleywiser``
…thomcc Clarify safety concern of `io::Read::read` is only relevant in unsafe code We have this clarification note in other similar place like [Iterator::size_hint](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.size_hint). The lack of clarification might lead to confusion to Rust beginners. [Relevant URLO post](https://users.rust-lang.org/t/can-read-overflow-a-buffer/94347).
Add test for RPIT defined with different hidden types with different substs Close rust-lang#111943
Correct comment on privately uninhabited pattern. Follow-up to rust-lang#111624 (comment) r? `@Nadrieril`
@bors r+ rollup=never p=6 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: be72f2587c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (1221e43): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 643.81s -> 644.999s (0.18%) |
Successful merges:
io::Read::read
is only relevant in unsafe code #111940 (Clarify safety concern ofio::Read::read
is only relevant in unsafe code)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup