Skip to content
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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

madsmtm
Copy link
Contributor

@madsmtm madsmtm commented Aug 21, 2024

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

@rustbot rustbot added O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 21, 2024
@jieyouxu
Copy link
Member

I'd also like some input on how to add a test for these kinds of incremental compilation changes?

If the incremental test suite doesn't suit your needs, you could fallback to a run-make test if needed.

@madsmtm madsmtm force-pushed the track-deployment-target branch from c9de51d to ed9370b Compare August 21, 2024 13:23
@rustbot rustbot added the A-run-make Area: port run-make Makefiles to rmake.rs label Aug 21, 2024
@madsmtm
Copy link
Contributor Author

madsmtm commented Aug 21, 2024

I'd also like some input on how to add a test for these kinds of incremental compilation changes?

If the incremental test suite doesn't suit your needs, you could fallback to a run-make test if needed.

Thanks for the tip, I took a look at the incremental test suite, but ended up creating a run-make test instead. Note that this change is going to conflict with #128507, since I updated the test from in there.

@rust-log-analyzer

This comment has been minimized.

@madsmtm madsmtm force-pushed the track-deployment-target branch from ed9370b to dc8b9f9 Compare August 21, 2024 13:37
@rust-log-analyzer

This comment has been minimized.

@madsmtm madsmtm force-pushed the track-deployment-target branch from dc8b9f9 to fb6ccd3 Compare August 21, 2024 15:23
@rust-log-analyzer

This comment has been minimized.

@madsmtm madsmtm force-pushed the track-deployment-target branch from fb6ccd3 to a45f61f Compare August 21, 2024 15:31
@jieyouxu
Copy link
Member

Note that this change is going to conflict with #128507, since I updated the test from in there.

I'll discuss this with @Oneirical, if this PR is updating the macos deployment test we might as well drop the port in #128507.

@rust-log-analyzer

This comment has been minimized.

@jieyouxu jieyouxu self-assigned this Aug 21, 2024
compiler/rustc_driver_impl/src/lib.rs Outdated Show resolved Hide resolved
compiler/rustc_interface/src/passes.rs Show resolved Hide resolved
compiler/rustc_interface/src/passes.rs Show resolved Hide resolved
compiler/rustc_target/src/spec/base/apple/mod.rs Outdated Show resolved Hide resolved
tests/run-make/apple-deployment-target/rmake.rs Outdated Show resolved Hide resolved
@madsmtm madsmtm force-pushed the track-deployment-target branch from a45f61f to 41c0b45 Compare August 21, 2024 17:23
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Aug 21, 2024
@madsmtm madsmtm force-pushed the track-deployment-target branch from 41c0b45 to c945329 Compare August 21, 2024 18:32
@madsmtm madsmtm force-pushed the track-deployment-target branch from c945329 to 23bd0d5 Compare August 21, 2024 18:56
@bors

This comment was marked as resolved.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 9, 2024
…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
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 9, 2024
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
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Sep 10, 2024
…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.
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Sep 10, 2024
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
@petrochenkov
Copy link
Contributor

Just to make sure I understand correctly, I would add a query env_var in compiler/rustc_middle/src/query/mod.rs?

Yes, seems about right.

And then in another PR I would change llvm_target to be versionless in target specs, and make the deployment target be loaded using the query instead?

Yep.

Should that also be a query like query deployment_target, or should that just be a regular method that calls env_var internally?

Just env_var query should be enough for a start.

I'm also gonna need the ability to mark certain system file paths as part of the incremental cache

This is better left for the last, I don't think we are currently doing anything like that in the compiler.

It seems like the TyCtx<'_> no longer exists when add_order_independent_options is called?

add_order_independent_options has the codegen_results.crate_info in arguments, tcx is available when it is constructed.

@petrochenkov
Copy link
Contributor

#130068 has landed, unblocking.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Sep 13, 2024
@madsmtm
Copy link
Contributor Author

madsmtm commented Sep 14, 2024

It seems like the TyCtx<'_> no longer exists when add_order_independent_options is called?

add_order_independent_options has the codegen_results.crate_info in arguments, tcx is available when it is constructed.

Ah, I see now, thanks!

I will try to find some time next week to implement what we've discussed.

lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Sep 25, 2024
…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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 27, 2024
…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`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 27, 2024
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`
@rustbot rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 10, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 1, 2024
…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`
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 2, 2024
…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```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 2, 2024
…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````
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 2, 2024
…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`````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 2, 2024
…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``````
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 2, 2024
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``````
@bors
Copy link
Contributor

bors commented Nov 2, 2024

☔ The latest upstream changes (presumably #132497) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC
Copy link
Member

@madsmtm any updates on this? thanks

@Dylan-DPC Dylan-DPC added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Nov 10, 2024
@petrochenkov
Copy link
Contributor

This is currently blocked on #130883.
@rustbot blocked

@rustbot rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc O-apple Operating system: Apple (macOS, iOS, tvOS, visionOS, watchOS) S-blocked Status: Blocked on something else such as an RFC or other implementation work. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rebuild if deployment target changes
8 participants