-
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
Rebuild on changes to the deployment target when compiling Apple targets #129342
base: master
Are you sure you want to change the base?
Conversation
If the incremental test suite doesn't suit your needs, you could fallback to a run-make test if needed. |
c9de51d
to
ed9370b
Compare
Thanks for the tip, I took a look at the incremental test suite, but ended up creating a |
This comment has been minimized.
This comment has been minimized.
ed9370b
to
dc8b9f9
Compare
This comment has been minimized.
This comment has been minimized.
dc8b9f9
to
fb6ccd3
Compare
This comment has been minimized.
This comment has been minimized.
fb6ccd3
to
a45f61f
Compare
I'll discuss this with @Oneirical, if this PR is updating the macos deployment test we might as well drop the port in #128507. |
This comment has been minimized.
This comment has been minimized.
a45f61f
to
41c0b45
Compare
41c0b45
to
c945329
Compare
c945329
to
23bd0d5
Compare
This comment was marked as resolved.
This comment was marked as resolved.
…jieyouxu Test codegen when setting deployment target Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture. Tested locally using: ```console ./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" ``` The only Apple targets that aren't tested by the above command are: - `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205. - `armv7k-apple-watchos`, failed to link, see rust-lang#130071. - `arm64e-apple-ios`, failed to link, see rust-lang#130085. - `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html). - `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030. But all of this is as it was before this PR. Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`. Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already. r? petrochenkov ```@rustbot``` label O-apple
Rollup merge of rust-lang#130068 - madsmtm:deployment-target-test, r=jieyouxu Test codegen when setting deployment target Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang#129342, rust-lang#129367 and rust-lang#129369. See rust-lang#129432 for the bigger picture. Tested locally using: ```console ./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" ``` The only Apple targets that aren't tested by the above command are: - `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205. - `armv7k-apple-watchos`, failed to link, see rust-lang#130071. - `arm64e-apple-ios`, failed to link, see rust-lang#130085. - `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html). - `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030. But all of this is as it was before this PR. Fixes rust-lang#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`. Split out from rust-lang#129342, see that for a little bit of the review that this has gone through already. r? petrochenkov ```@rustbot``` label O-apple
…enkov Apple: Refactor deployment target version parsing Refactor deployment target parsing to make it easier to do rust-lang/rust#129342 (I wanted to make sure of all the places that `std::env::var` is called). Specifically, my goal was to minimize the amount of target-specific configuration, so to that end I renamed the `opts` function that generates the `TargetOptions` to `base`, and made it return the LLVM target and `target_arch` too. In the future, I would like to move even more out of the target files and into `spec::apple`, as it makes it easier for me to maintain. For example, this fixed a bug in `aarch64-apple-watchos`, which wasn't passing the deployment target as part of the LLVM triple. This (probably) fixes rust-lang/rust#123582 and fixes rust-lang/rust#107630. We also now parse the patch version of deployment targets, allowing the user to specify e.g. `MACOSX_DEPLOYMENT_TARGET=10.12.6`. Finally, this fixes the LLVM target name for visionOS, it should be `*-apple-xros` and not `*-apple-visionos`. Since I have changed all the Apple targets here, I smoke-tested my changes by running the following: ```console # Build each target ./x build library --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,arm64e-apple-ios,armv7k-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" # Test that we can still at least link basic projects cargo new foobar && cd foobar && cargo +stage1 build --target=aarch64-apple-darwin --target=aarch64-apple-ios --target=aarch64-apple-ios-macabi --target=aarch64-apple-ios-sim --target=aarch64-apple-tvos --target=aarch64-apple-tvos-sim --target=aarch64-apple-visionos --target=aarch64-apple-visionos-sim --target=aarch64-apple-watchos --target=aarch64-apple-watchos-sim --target=arm64_32-apple-watchos --target=armv7s-apple-ios --target=i386-apple-ios --target=x86_64-apple-darwin --target=x86_64-apple-ios --target=x86_64-apple-ios-macabi --target=x86_64-apple-tvos --target=x86_64-apple-watchos-sim --target=x86_64h-apple-darwin ``` I couldn't build for the `arm64e-apple-darwin` target, the `armv7k-apple-watchos` and `arm64e-apple-ios` targets failed to link, and I know that the `i686-apple-darwin` target requires a bit of setup, but all of this is as it was before this PR. r? thomcc CC `@BlackHoleFox` I would recommend using `rollup=never` when merging this, in case we need to bisect this later.
Test codegen when setting deployment target Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in rust-lang/rust#129342, rust-lang/rust#129367 and rust-lang/rust#129369. See rust-lang/rust#129432 for the bigger picture. Tested locally using: ```console ./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" ``` The only Apple targets that aren't tested by the above command are: - `arm64e-apple-darwin`, failed to build, see rust-lang/cc-rs#1205. - `armv7k-apple-watchos`, failed to link, see rust-lang/rust#130071. - `arm64e-apple-ios`, failed to link, see rust-lang/rust#130085. - `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html). - `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by rust-lang/cc-rs#1030. But all of this is as it was before this PR. Fixes rust-lang/rust#47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`. Split out from rust-lang/rust#129342, see that for a little bit of the review that this has gone through already. r? petrochenkov ```@rustbot``` label O-apple
Yes, seems about right.
Yep.
Just
This is better left for the last, I don't think we are currently doing anything like that in the compiler.
|
Ah, I see now, thanks! I will try to find some time next week to implement what we've discussed. |
…enkov Apple: Refactor deployment target version parsing Refactor deployment target parsing to make it easier to do rust-lang/rust#129342 (I wanted to make sure of all the places that `std::env::var` is called). Specifically, my goal was to minimize the amount of target-specific configuration, so to that end I renamed the `opts` function that generates the `TargetOptions` to `base`, and made it return the LLVM target and `target_arch` too. In the future, I would like to move even more out of the target files and into `spec::apple`, as it makes it easier for me to maintain. For example, this fixed a bug in `aarch64-apple-watchos`, which wasn't passing the deployment target as part of the LLVM triple. This (probably) fixes rust-lang/rust#123582 and fixes rust-lang/rust#107630. We also now parse the patch version of deployment targets, allowing the user to specify e.g. `MACOSX_DEPLOYMENT_TARGET=10.12.6`. Finally, this fixes the LLVM target name for visionOS, it should be `*-apple-xros` and not `*-apple-visionos`. Since I have changed all the Apple targets here, I smoke-tested my changes by running the following: ```console # Build each target ./x build library --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,arm64e-apple-ios,armv7k-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" # Test that we can still at least link basic projects cargo new foobar && cd foobar && cargo +stage1 build --target=aarch64-apple-darwin --target=aarch64-apple-ios --target=aarch64-apple-ios-macabi --target=aarch64-apple-ios-sim --target=aarch64-apple-tvos --target=aarch64-apple-tvos-sim --target=aarch64-apple-visionos --target=aarch64-apple-visionos-sim --target=aarch64-apple-watchos --target=aarch64-apple-watchos-sim --target=arm64_32-apple-watchos --target=armv7s-apple-ios --target=i386-apple-ios --target=x86_64-apple-darwin --target=x86_64-apple-ios --target=x86_64-apple-ios-macabi --target=x86_64-apple-tvos --target=x86_64-apple-watchos-sim --target=x86_64h-apple-darwin ``` I couldn't build for the `arm64e-apple-darwin` target, the `armv7k-apple-watchos` and `arm64e-apple-ios` targets failed to link, and I know that the `i686-apple-darwin` target requires a bit of setup, but all of this is as it was before this PR. r? thomcc CC `@BlackHoleFox` I would recommend using `rollup=never` when merging this, in case we need to bisect this later.
…trochenkov Move Apple linker args from `rustc_target` to `rustc_codegen_ssa` They are dependent on the deployment target and SDK version, but having these in `rustc_target` makes it hard to introduce that dependency. Part of the work needed to do rust-lang#118204, see rust-lang#129342 for some discussion. Tested using: ```console ./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-deployment-target --target=i386-apple-ios ``` `arm64e-apple-darwin` and `arm64e-apple-ios` have not been tested, see rust-lang#130085, neither is `i686-apple-darwin`, since that requires using an x86_64 macbook, and I currently can't get mine to work, see rust-lang#130434. CC `@petrochenkov`
Rollup merge of rust-lang#130435 - madsmtm:move-apple-link-args, r=petrochenkov Move Apple linker args from `rustc_target` to `rustc_codegen_ssa` They are dependent on the deployment target and SDK version, but having these in `rustc_target` makes it hard to introduce that dependency. Part of the work needed to do rust-lang#118204, see rust-lang#129342 for some discussion. Tested using: ```console ./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7k-apple-watchos,armv7s-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin" IPHONEOS_DEPLOYMENT_TARGET=10.0 ./x test tests/run-make/apple-deployment-target --target=i386-apple-ios ``` `arm64e-apple-darwin` and `arm64e-apple-ios` have not been tested, see rust-lang#130085, neither is `i686-apple-darwin`, since that requires using an x86_64 macbook, and I currently can't get mine to work, see rust-lang#130434. CC `@petrochenkov`
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? `@petrochenkov`
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ```@petrochenkov```
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ````@petrochenkov````
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? `````@petrochenkov`````
…g, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ``````@petrochenkov``````
Rollup merge of rust-lang#131037 - madsmtm:move-llvm-target-versioning, r=petrochenkov Move versioned Apple LLVM targets from `rustc_target` to `rustc_codegen_ssa` Fully specified LLVM targets contain the OS version on macOS/iOS/tvOS/watchOS/visionOS, and this version depends on the deployment target environment variables like `MACOSX_DEPLOYMENT_TARGET`, `IPHONEOS_DEPLOYMENT_TARGET` etc. We would like to move this to later in the compilation pipeline, both because it feels impure to access environment variables when fetching target information, but mostly because we need access to more information from rust-lang#130883 to do rust-lang#118204. See also rust-lang#129342 (comment) for some discussion. The first and second commit does the actual refactor, it should be a non-functional change, the third commit adds diagnostics for invalid deployment targets, which are now possible to do because we have access to the session. Tested with the same commands as in rust-lang#130435. r? ``````@petrochenkov``````
☔ The latest upstream changes (presumably #132497) made this pull request unmergeable. Please resolve the merge conflicts. |
@madsmtm any updates on this? thanks |
Rebuild, both in Cargo and the incremental cache, when the
*_DEPLOYMENT_TARGET
environment variables change.Fixes #118204. See #129432 for more motivation behind this change.
I am a bit unsure if I have implemented this correctly, I'm particularly uncertain whether creating a new field in
Options
the correct approach for busting the incremental cache? It's only the codegen that needs to be re-run, everything before that shouldn't be influenced by this, so if there's a way to make that happen, we should do that instead.Builds upon #130068.
r? thomcc
CC @BlackHoleFox
@rustbot blocked