-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Defer Apple SDKROOT detection to link time. #77202
Conversation
I misunderstood how this works, and I have fixed the linux builds to support ios/tvos.
r? @lcnr (rust_highfive has picked a reviewer for you, use r? to override) |
Not something I can review r? @Mark-Simulacrum for review or reassignment |
LGTM, except that I'd move (Can't say anything about the tvOS changes though.)
This change affects all target specs, better do it in a separate PR. |
I feel like we should at least split the tvOS change into a separate commit (if not PR). I don't think we have anyone (maybe even anyone we can ping) that can answer questions on what the proper thing is for those platforms, but I'm not inclined to block seemingly correct changes on tracking someone down either. |
FWIW, I pulled this PR into #77239 where I was doing a try build for aarch64-apple-darwin and the build succeeded. |
Yea, I couldn't decide where to put it. It doesn't really fit in
I can't really do that. The SDK is chosen by the target_os in the Target. I could just swap @simlay, can you answer the questions here? It looks like this line should have used |
Bleh. It looks like I screwed up in that PR. My bad. I was trying to refactor it so we could add watchOS without much work.
Yes.
Yes.
This I unfortunately do not know. This PR is good. It makes the logic clearer. Once someone figures out the the |
It looks like @ehuss implemented what @petrochenkov asked for -- I am going to r? @petrochenkov since this is not an area I'm familiar with. |
@bors r+ |
📌 Commit 7420d7a has been approved by |
Rollup of 12 pull requests Successful merges: - rust-lang#76909 (Add Iterator::advance_by and DoubleEndedIterator::advance_back_by) - rust-lang#77153 (Fix recursive nonterminal expansion during pretty-print/reparse check) - rust-lang#77202 (Defer Apple SDKROOT detection to link time.) - rust-lang#77303 (const evaluatable: improve `TooGeneric` handling) - rust-lang#77305 (move candidate_from_obligation_no_cache) - rust-lang#77315 (Rename AllocErr to AllocError) - rust-lang#77319 (Stable hashing: add comments and tests concerning platform-independence) - rust-lang#77324 (Don't fire `const_item_mutation` lint on writes through a pointer) - rust-lang#77343 (Validate `rustc_args_required_const`) - rust-lang#77349 (Update cargo) - rust-lang#77360 (References to ZSTs may be at arbitrary aligned addresses) - rust-lang#77371 (Remove trailing space in error message) Failed merges: r? `@ghost`
Do you still plan to make this change? |
I was not planning to do that in the foreseeable future. Please go ahead! |
rustc_target: Refactor away `TargetResult` Follow-up to rust-lang#77202. Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary. The second commit contains some further cleanup based on built-in target construction being infallible.
…eyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. `@rustbot` label O-macos A-cross
…eyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. ``@rustbot`` label O-macos A-cross
Rollup merge of rust-lang#130334 - madsmtm:macos-sdkroot-ignore, r=jieyouxu Fix `SDKROOT` ignore on macOS `rustc` has code to detect when `SDKROOT` is obviously set for the wrong platform, so that it can choose to ignore it. This is a pretty important feature for Cargo build scripts and proc macros, since you will often have `SDKROOT` set to an iOS platform there. However, the code was checking for an old SDK version name `"macosx10.15"` that was previously configured by `add_apple_sdk`, but nowadays configured to the correct `"macosx"`. I think this error was introduced in part rust-lang#77202 and in rust-lang#100286. Fixes part of rust-lang#80817 (linking with `-Clinker=ld` now works), though more work is still needed in this area, see also rust-lang#129432. ``@rustbot`` label O-macos A-cross
This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the
Target
is defined. This allows commands that don't need to link to work (likerustdoc
orrustc --print=target-list
). This also makes--print=target-list
a bit faster.This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked.
Notes:
x86_64-apple-tvos
to useappletvsimulator
. I think the original code was wrong (it was usingiphonesimulator
). Also,x86_64-apple-tvos
seems broken in general, and I cannot build it locally. Thedata_layout
does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements).Result
for built-in target definitions, since I don't think they should be fallible. This was added in Convert built-in targets to JSON #34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not.Fixes #36156
Fixes #76584