-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix issues with excluding macros/plugins from dependency computation #6723
Conversation
While fixing this, I also noticed the original issue also exists for executable targets, so this gets fixed here as well. There's one unfortunate nuance here for test targets since using a macro/plugin is indistinguishable from needing to link it because it is being tested. We err on the side of caution here and will always link. (sidenote: theoretically, plugins *do* distinguish between linkage and use in the package manifest, but this distinction is not carried forward into the actual model) Partially fixes https://github.com/apple/swift/issues/67371 since the underlying project also does not declare a dependency on the macro that is being tested.
We will also need this fix in 5.9 and to fix the source compatibility issue, we will need the underlying package to make this change:
It seems acceptable to have a breaking change here since 5.9 is not final yet. For executable/plugin, the change is gated on 5.9 as well, so we won't break any existing packages in this way. |
@swift-ci please smoke test |
seems fine, but do we need to add more test cases / fixtures? |
Yep, definitely needed, also our coverage of macros is poor in general. Will address both in followups in order to not leave this broken for too long. |
lol, I was confused why there's content missing from my commit message and the issue is that I wrote a paragraph that started with swiftlang/swift#6695, referencing the original issue, but of course that is treated by git as a comment |
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012 (cherry picked from commit 00a64df)
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012 (cherry picked from commit 00a64df)
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012
A previous problem here was fixed in #6723, this new fix is attempting to resolve issues where macros are used transitively by a product that a test is depending on. It seems to me that those transitively available macros should not be statically linked into tests and in fact doing so can cause various issues such as linker errors on non-Darwin platforms. It does feel like eventually we need to get away from `computeDependencies(of:)` being a computation on the entire package graph and instead let each package produce separate products which we can then just use transitively, but that is a much bigger change to SwiftPM's build system. rdar://115071012
While fixing this, I also noticed the original issue also exists for executable targets, so this gets fixed here as well.
There's one unfortunate nuance here for test targets since using a macro/plugin is indistinguishable from needing to link it because it is being tested. We err on the side of caution here and will always link.
(sidenote: theoretically, plugins do distinguish between linkage and use in the package manifest, but this distinction is not carried forward into the actual model)
Partially fixes swiftlang/swift-source-compat-suite#833 since the underlying project also does not declare a dependency on the macro that is being tested.