-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
base: main
Are you sure you want to change the base?
Conversation
hnrklssn
commented
Feb 20, 2025
This depends on Clang changes in swiftlang/llvm-project#10068 |
lib/ClangImporter/ImportDecl.cpp
Outdated
return false; | ||
|
||
printSeparator(); | ||
out << ".method(name: \"" << Method->getName().getBaseIdentifier() |
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.
Will this work for overloaded methods?
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.
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.
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.
This now passes the entire method signature to disambiguate overloaded methods
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.
67daddc
to
93e659b
Compare
@swift-ci please smoke test |