Rollup of 7 pull requests #111981
Closed
Rollup of 7 pull requests #111981
Conversation
This file contains 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
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
This fixes rust-lang#111220 by checking the privacy of tuple constructors using `Self`, so the following code now errors ```rust mod my { pub struct Foo(&'static str); } impl AsRef<str> for my::Foo { fn as_ref(&self) -> &str { let Self(s) = self; // previously compiled, now errors correctly s } } ```
As per review request.
…truct-field, r=lcnr fix for `Self` not respecting tuple Ctor privacy This PR fixes rust-lang#111220 by checking the privacy of tuple constructors using `Self`, so the following code now errors ```rust mod my { pub struct Foo(&'static str); } impl AsRef<str> for my::Foo { fn as_ref(&self) -> &str { let Self(s) = self; // previously compiled, now errors correctly s } } ```
…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).
…-translatable, r=oli-obk Use translatable diagnostics in `rustc_const_eval` This PR: * adds a `no_span` parameter to `note` / `help` attributes when using `Subdiagnostic` to allow adding notes/helps without using a span * has minor tweaks and changes to error messages
…wiser CGU cleanups Some code clarity improvements I found when reading this code closely. r? `@wesleywiser`
…r, r=lcnr Use `ErrorGuaranteed` more in MIR type ops Delay bugs more eagerly and pass them through type op infra instead of delaying them at all the usage-sites. Follow up to: rust-lang#111741 (comment) r? `@lcnr`
…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
rustbot
added
A-translation
|
@bors r+ rollup=never p=7 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
|
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message |
bors
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #111858) made this pull request unmergeable. Please resolve the merge conflicts. |
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:
Selfnot respecting tuple Ctor privacy #111245 (fix forSelfnot respecting tuple Ctor privacy)rustc_const_eval#111677 (Use translatable diagnostics inrustc_const_eval)ErrorGuaranteedmore in MIR type ops #111918 (UseErrorGuaranteedmore in MIR type ops)io::Read::readis only relevant in unsafe code #111940 (Clarify safety concern ofio::Read::readis only relevant in unsafe code)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup