Rollup of 12 pull requests #63588
Closed
Rollup of 12 pull requests #63588
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
Hard-float (unlike mips32 musl targets but consistent with any other musl target), MIPS64r2, n64 ABI. The triples are renamed to carry the `abi64` ABI suffix found on all other MIPS64 targets, for consistency and forward compatibility, should Rust gain support for the n32 ABI one day.
This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu, iOS SDK, linked agains the iOS ABI - Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI. Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.
Co-Authored-By: bjorn3 <[email protected]>
That way, callers don't need to repeat "let's add this to sm manually for tracking dependencies" trick. It should make it easier to switch to using `FileLoader` for binary files in the future as well
Add UWP MSVC targets Hi, - The README URI change is the correct one for VS2019 community edition, which I suspect most people would use. Doesn't _need_ to be merged though. - This rust-lang@5e6619e fixes the UWP build (msvc or not, doesn't matter). I suspect it broke with recent changes unnoticed because no CI. - Store lib location is found through the VCToolsInstallDir env variable. The end of the path is currently for the VS2019 store lib locations only. - I could not test the aarch64_uwp_windows_msvc target because the rust build script does not currently support arm64 msvc AFAIU.
…ichton Add builtin targets for mips64(el)-unknown-linux-muslabi64 This is prerequisite for rust-lang/libc#1449. Tested locally to produce working static and dynamic binaries, ~~but CI config is untested for now~~ CI is to be added in a follow-up PR. *edit: dynamic binaries also confirmed working!* *edit 2: changed triples to include ABI, and removed stray `crt_static_default = false` declarations to be consistent with other musl targets*
…bi-target-triple, r=estebank Add Catalyst (iOS apps running on macOS) target This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu, iOS SDK, linked agains the iOS ABI - Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI. Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made. # Open Questions: ## Clang Version It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode) ## Hardcoded iOS version `swift-llvm` actually used [x86_64-apple-ios13.0-macabi](apple/swift-llvm@3f1fd4f) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome. ## Data Layout I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK. # Current State 1. I got it to compile 2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi` I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here. # Additional Information - [Commit adding Catalyst support to the Swift Clang Fork](CocoaPods/CocoaPods#8877) - [Compiling C to Catalyst Discussion](CocoaPods/CocoaPods#8877) - [CocoaPods Discussion on Adding Catalyst support](CocoaPods/CocoaPods#8877)
…xcrichton Utilize -Zbinary-dep-depinfo in rustbuild The last commit moves us over to using binary-dep-depinfo while the first two permit us to bootstrap from what will become future beta, to be released in the next week (it's the `cfg(bootstrap)` processing). We no longer utilize stamp-file mtimes at all inside rustbuild, and a future PR may be able to entirely eliminate them by eagerly copying to the appropriate sysroot. The only mtime-based dependency tracking left is for documentation because we lie to Cargo about the rustdoc binary, so Cargo does not track changes to the real binary, and codegen-backends because binary-dep-depinfo does not emit that information into the depfiles. Both of these are fixable in the longer term but this existing patch gives us the following benefits: * We no longer delete Cargo target directories manually within a stage. Cross-stage, changes to codegen backends will still clear out target directories. This means that incremental state persists across individual steps (e.g., rebuilding libstd does not clear out librustc incremental state). Fixes rust-lang#54712. * Dependency tracking across steps within a given stage is now fully precise. We will not clear out all codegen backend dependencies due to changes in librustc_driver, for example, only deleting the final librustc_codegen_llvm crate. Fixes rust-lang#54008, fixes rust-lang#50481. * We properly track codegen backends as a dependency (equivalent to rustc) across changes. Fixes rust-lang#53284, and fixes rust-lang#52719. * Cross-stage dependency tracking of crates is also much more accurate and reliable. Most likely fixes rust-lang#49979 (but no reproduction steps in that issue). Fixes rust-lang#59105. cc rust-lang#63012
Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`. Fixes rust-lang#56137. As a side-effect, associated const literals have the correct type now, which should make things easier for rust-lang#61041. r? @oli-obk / @matthewjasper cc @davidtwco @varkor
…petrochenkov Make sure that all file loading happens via SourceMap That way, callers don't need to repeat "let's add this to sm manually for tracking dependencies" trick. It should make it easier to switch to using `FileLoader` for binary files in the future as well cc rust-lang#62948 r? @petrochenkov
…fJung Remove uses of `mem::uninitialized()` from cloudabi This PR removes uses of `mem::uninitialized` from `cloudabi` module, excluding the layout test in `src/libstd/sys/cloudabi/abi/cloudabi.rs`. r? @RalfJung cc @EdSchouten cc rust-lang#62397
rustc_codegen_utils: account for 1-indexed anonymous lifetimes in v0 mangling. I don't really understand why `anonymize_late_bound_regions` starts with `BrAnon(1)` instead of `BrAnon(0)`, but it does (maybe @nikomatsakis knows?): https://github.com/rust-lang/rust/blob/c43d03a19f326f4a323569328cc501e86eb6d22e/src/librustc/ty/fold.rs#L696-L712 Thankfully, the mangling format and demangler implementations are fine, and I just needed to offset the anonymized lifetime indices by `1` to get the correct mangling. cc @alexcrichton @michaelwoerister
remove unused Level::PhaseFatal r? @estebank
Test HRTB issue accepted by compiler Hi! First Rust PR, so if anything needs changing just let me know and I'll take care of it right away. Closes rust-lang#50301 which was marked E-needstest
cleanup: Remove `Spanned` where possible It generally only makes sense on enums, otherwise it's more convenient to "flatten" it by adding a span field to the struct it wraps.
|
@bors r+ p=12 rollup=never |
|
📌 Commit 432e886 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 432e886 with merge a3687de17292dd7d9f4a4105cce10bdc521fbff7... |
|
💔 Test failed - checks-azure |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
added
S-waiting-on-review
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:
tyfields frommir::Constantandhair::pattern::PatternRange. #63495 ( Remove redundanttyfields frommir::Constantandhair::pattern::PatternRange.)mem::uninitialized()from cloudabi #63546 (Remove uses ofmem::uninitialized()from cloudabi)Spannedwhere possible #63586 (cleanup: RemoveSpannedwhere possible)Failed merges:
r? @ghost