This removes the swiftifyProtocol function, because it fundamentally
incompatible with our layering. By iterating over the protocol members
of the node we are currently importing, we immediately force all members
to be imported. This can lead to cycles and various hard-to-debug import
failures. Instead we need to attach the extension macro when importing
each invidvidual method. This will take some plumbing however, because
that may happen after the protocol's macros have already been expanded,
preventing later macros from being expanded.
rdar://168500103
These cases would trigger an assert in both release and debug builds.
With this change they are ignored in release mode, and cases that are
both unhandled and unknown trigger an assert in debug mode.
rdar://166074719
This updates SwiftifyImportProtocolPrinter such that it no longer emits
anything for methods without bounds or lifetime info. Previously we
would not attach the macro if no methods in the protocol contained
bounds or lifetime info. However if one of the methods did, we would
still emit `.method(signature: "func foo()", paramInfo: [])` for the
methods without bounds of lifetime info. This would result in overloads
being generated, like so:
```
@_alwaysEmitIntoClient @_disfavoredOverload public
func foo() {
return unsafe foo()
}
```
As part of this change, SwiftifyImportPrinter is now an abstract parent
type for SwiftifyImportProtocolPrinter, and the new
SwiftifyImportFunctionPrinter. Instead of SwiftifyImportProtocolPrinter
inheriting the function printing, `printMethod` instead creates a new
SwiftifyImportFunctionPrinter each time, with a new output string. If it
output anything interesting the result is forwarded, otherwise it is
discarded.
...with bounds attributes
This creates safe overloads for any methods in the protocol annotated
with bounds information. Updates _SwiftifyImportProtocol to make the
added overloads in the protocol public.
rdar://144335990
Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.
To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.
rdar://151206394
_SwiftifyImport doesn't know how to handle
AutoreleasingUnsafeMutablePointer, so we should not attach any
.countedBy information for pointers that are imported as this type.
This also adds defensive checks against adding .countedBy to any pointer
type that _SwiftifyImport doesn't know how to transform.
rdar://151479521
