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

Fix issues with excluding macros/plugins from dependency computation #6723

Merged
merged 1 commit into from
Jul 19, 2023

Conversation

neonichu
Copy link
Contributor

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.

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.
@neonichu
Copy link
Contributor Author

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:

diff --git a/Package.swift b/Package.swift
index b646e1d..c0595bc 100644
--- a/Package.swift
+++ b/Package.swift
@@ -64,6 +64,7 @@ let package = Package(
       name: "PowerAssertTests",
       dependencies: [
         "PowerAssert",
+        "PowerAssertPlugin",
         .product(name: "SwiftSyntaxMacrosTestSupport", package: "swift-syntax"),
       ]
     ),

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.

@neonichu
Copy link
Contributor Author

@swift-ci please smoke test

@tomerd
Copy link
Contributor

tomerd commented Jul 18, 2023

seems fine, but do we need to add more test cases / fixtures?

@neonichu
Copy link
Contributor Author

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.

@neonichu
Copy link
Contributor Author

neonichu commented Jul 18, 2023

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

@neonichu neonichu merged commit b31c19a into main Jul 19, 2023
@neonichu neonichu deleted the fix-plugin-exclusion branch July 19, 2023 03:09
neonichu added a commit that referenced this pull request Sep 6, 2023
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
neonichu added a commit that referenced this pull request Sep 8, 2023
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
neonichu added a commit that referenced this pull request Sep 11, 2023
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)
neonichu added a commit that referenced this pull request Sep 11, 2023
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)
MaxDesiatov pushed a commit that referenced this pull request Sep 28, 2023
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
MaxDesiatov pushed a commit that referenced this pull request Sep 28, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Source compatibility suite] swift-power-assert failing to build - Undefined symbols
2 participants