Skip to content

[ClangImporter][Swiftify] Add _SwiftifyImportProtocol for safe overloads for protocols #79510

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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

hnrklssn
Copy link
Contributor

The existing _SwiftifyImport macro is a peer macro, limiting it to only
emitting function wrappers in the same scope as the original function.
Protocols cannot contain function implementations, so these need to be
placed in a separate protocol extension instead. _SwiftifyImportProtocol
is an extension macro rather than a peer macro, to enable this
functionality.

Rather than operating on a single function, like _SwiftifyImport,
_SwiftifyImportProtocol takes information about multiple methods and
creates a single protocol extension with all wrappers in a one-shot
operation. ClangImporter automatically attaches _SwiftifyImportProtocol
macros to imported protocols with methods annotated with bounds info.

rdar://144335990

@hnrklssn
Copy link
Contributor Author

This depends on Clang changes in swiftlang/llvm-project#10068

return false;

printSeparator();
out << ".method(name: \"" << Method->getName().getBaseIdentifier()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work for overloaded methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm that's a really good point actually... I'm guessing macros don't have access to mangled names of declarations, otherwise comparing the mangled name instead could work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now passes the entire method signature to disambiguate overloaded methods

hnrklssn added 10 commits April 24, 2025 14:59
The existing _SwiftifyImport macro is a peer macro, limiting it to only
emitting function wrappers in the same scope as the original function.
Protocols cannot contain function implementations, so these need to be
placed in a separate protocol extension instead. _SwiftifyImportProtocol
is an extension macro rather than a peer macro, to enable this
functionality.

Rather than operating on a single function, like _SwiftifyImport,
_SwiftifyImportProtocol takes information about multiple methods and
creates a single protocol extension with all wrappers in a one-shot
operation.

rdar://144335990
`registerStdSpanTypeMapping` used to be a lambda inside `swiftify`.
By moving it, along with the `typeMapping` state, inside
`SwiftifyInfoPrinter` we will simplify changes necessary to support
`_SwiftifyImportProtocol` in ClangImporter.
with bounds attributes

This creates safe overloads for any methods in the protocol annotated
with bounds information.

rdar://144335990
To disambiguate overloaded methods in _SwiftifyImportProtocol we now
pass the entire function signature instead of just the function name.
This should be reflected in the parameter name.
We previously asserted that a variable contained a FileUnit, but the
intention of this was to separate it from SourceFiles, and SourceFile is
a subtype of FileUnit, so it wouldn't trigger if the variable actually
contained a SourceFile.
This was only passed to _SwiftifyImportProtocol, now it is also
passed to _SwiftifyImport. This results in @available being attached to
generated overloads that use [Mutable][Raw]Span.
Escapable inout parameters don't have an implicit lifetime that can be
borrowed or copied, because the caller doesn't know what the lifetime of
the new value is, if the callee writes to the parameter. Depending on
the lifetime of an Escapable inout parameter without explicit lifetime
annotation results in an error, so _SwiftifyImport should not do that.
@hnrklssn hnrklssn requested a review from Xazax-hun April 29, 2025 06:13
@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

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.

2 participants