-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Frontend: allow specifying a different target triple for internal clang instance to use #37774
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
Conversation
@swift-ci please smoke test |
swiftlang/swift-driver#698 |
swiftlang/swift-driver#698 |
swiftlang/swift-driver#698 |
swiftlang/swift-driver#698 |
c66bade
to
0ddf1b0
Compare
swiftlang/swift-driver#698 |
Build failed |
Build failed |
55adf0c
to
498b030
Compare
swiftlang/swift-driver#698 |
Build failed |
swiftlang/swift-driver#698 |
Build failed |
swiftlang/swift-driver#698 |
Build failed |
swiftlang/swift-driver#698 |
Build failed |
swiftlang/swift-driver#698 |
1 similar comment
swiftlang/swift-driver#698 |
Build failed |
Build failed |
@swift-ci please test |
Build failed |
…ng instance to use Before this change, we always use the Swift target triple to instantiate the internal Clang instance. When loading a Swift module from the textual interface, we may pick up a lower target triple to use to build the Swift module because the target is hard-coded in the textual interface file. This implies we may end up building multiple versions of the same Clang module, one for each target triple of the loading Swift module. This change adds a new frontend flag -clang-target to allow clients to specify a consistent clang target to use across the Swift module boundaries. This value won't change because it's not part of .swiftinterface files. swift-driver should pass down -clang-target for each frontend invocation, and its value should be identical to -target. Related to: rdar://72480261
@swift-ci please test |
Build failed |
@swift-ci Please smoke test OS X platform |
1 similar comment
@swift-ci Please smoke test OS X platform |
… scanning an interface swiftlang#37774 (related to rdar://72480261) has made it so that the target of built clang modules (even downstream from Swift interface dependencies) can be consistent with that of the main module. This means that when building transitive Clang dependencies of the main module, they will always have a matching triple to the main module itself (ensured with `-clang-target`). This means we no longer have to report the target triple in the set of `extraPCMArgs` which encode an interface-specific requirement for building its dependencies.
… scanning an interface swiftlang#37774 (related to rdar://72480261) has made it so that the target of built clang modules (even downstream from Swift interface dependencies) can be consistent with that of the main module. This means that when building transitive Clang dependencies of the main module, they will always have a matching triple to the main module itself (ensured with `-clang-target`). This means we no longer have to report the target triple in the set of `extraPCMArgs` which encode an interface-specific requirement for building its dependencies.
swiftlang#37774 added '-clang-target' which allows us to specify a target triple that only differs from '-target' by the OS version, when we want to provide a different OS version for API availability and type-checking, in order to set a common/unified target triple for the entire Clang module dependency graph, for presenting a unified API surface to the Swift client, serving as a maximum type-checking epoch. This change adds an equivalent flag for the '-target-variant' configuration, as a mechanism to ensure that the entire module dependency graph presents a consistent os version.
Before this change, we always use the Swift target triple to instantiate the internal
Clang instance. When loading a Swift module from the textual interface, we may pick up
a lower target triple to use to build the Swift module because the target is hard-coded
in the textual interface file. This implies we may end up building multiple versions of the
same Clang module, one for each target triple of the loading Swift module.
This change adds a new frontend flag -clang-target to allow clients to specify a
consistent clang target to use across the Swift module boundaries. This value won't change
because it's not part of .swiftinterface files.
swift-driver should pass down -clang-target for each frontend invocation, and its value should be
identical to -target.
Related to: rdar://72480261