-
Notifications
You must be signed in to change notification settings - Fork 440
Import _CSwiftSyntax using @_implementationOnly. #140
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! 🙏
I don't have any concerns about using @_implementationOnly
.
@swift-ci Please test |
Ah, it would be good for the implementation file to include its header. |
e59c675
to
d66ea53
Compare
Done! |
@@ -1,3 +1,5 @@ | |||
#include "atomic-counter.h" | |||
|
|||
#include <stdint.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick, this #include
can be removed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering if you'd ask me to remove that or not! I usually try not to rely on indirect inclusions for unrelated types, but since it's part of the signature in this case, it doesn't really matter. Done.
This lets us add an actual header for the C function it defines, so that Swift can import it directly (while still retaining the property that it is a standalone module) instead of relying on the dlsym trick that fails on Linux unless additional flags are passed to the linker for any binary that depends on SwiftSyntax (see https://bugs.swift.org/browse/SR-11293).
d66ea53
to
efd4dc8
Compare
Build failed |
@swift-ci Please test |
Build failed |
❤️ |
Expose finding ".swift-format" file
This lets us add an actual header for the C function it defines, so that Swift can import it directly (while still retaining the property that it is a standalone module) instead of relying on the
dlsym
trick that fails on Linux unless additional flags are passed to the linker for any binary that depends onSwiftSyntax
(see https://bugs.swift.org/browse/SR-11293).Note: I tested this by taking the resulting
SwiftSyntax.swiftmodule
and importing it into a context where the_CSwiftSyntax
module map wasn't present, and it succeeded, so the@_implementationOnly
import worked as intended. Even though this is currently a private feature, is there any reason we shouldn't move forward with this, since it's a cleaner fix for bugs like the one above than to ask folks on Linux to pass additional linker flags to all their executables?