[Clang importer] Don't bridge blocks to Swift functions in ObjC generic args #17247
Conversation
|
@swift-ci please smoke test |
…ic args. While the compiler can bridge C block types to Swift function types, the Swift runtime cannot. Don't bridge block types to Swift function types in Objective-C generic arguments, so NSArray<some-block-type> will get imported as [@convention(block) (...) -> Whatever] rather than [(...) -> Whatever] Fixes rdar://problem/40879067 in a fairly narrow way; the Clang importer's approach to adjusting types based on context needs a cleanup, but this is the safe, localized fix suitable for 4.2.
DougGregor
force-pushed
the
import-objc-generic-of-block
branch
from
3718cdc to
d529002
Compare
|
@swift-ci please smoke test and merge |
lib/ClangImporter/ImporterImpl.h
Outdated
| /// \brief Import the type of a literal value that can be bridged. | ||
| BridgedValue, | ||
| /// \brief Import the type of an Objective-C generic argument. | ||
| ObjCGenericArgument, |
There was a problem hiding this comment.
I feel like this isn't just any generic argument, since most of the time we'd import Foo<NSString *> * as Foo<NSString> and not Foo<String>. "ObjCCollectionElement", maybe?
| if (einfo.getRepresentation() != FunctionTypeRepresentation::Swift) { | ||
| einfo = einfo.withRepresentation(FunctionTypeRepresentation::Swift); | ||
| if (einfo.getRepresentation() != requiredFunctionTypeRepr) { | ||
| einfo = einfo.withRepresentation(requiredFunctionTypeRepr); |
There was a problem hiding this comment.
Since @convention(block) is the default, it seems simple to just change the condition here: canBridgeTypes(importKind) && importKind != ImportTypeKind::ObjCGenericArgument.
There was a problem hiding this comment.
This is the rathole I went down before, because the way in which we pass down the desired "bridgeability" of the imported type doesn't account for blocks, which are bridgeable in some positions but not others. The problem with simply trying to exclude ObjCGenericArgument here is that the mappedType we get here has already been given the Swift function type representation (because we're importing a typedef with "full bridgeability"), and we no longer have the block type around.
There was a problem hiding this comment.
Ah, typedefs. In that case, can you update the comment above?
…llectionElement. This better describes what we're importing. Also note why we need to reset to the block representation.
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
| @@ -1287,10 +1287,24 @@ static ImportedType adjustTypeForConcreteImport( | |||
| // we would prefer to instead use the default Swift convention. | |||
There was a problem hiding this comment.
Sorry, I meant this comment, which refers to @convention(block).
There was a problem hiding this comment.
Grrrr. That comment above is a lie. I'll do a separate comment-only PR for that
While the compiler can bridge C block types to Swift function types,
the Swift runtime cannot. Don't bridge block types to Swift function
types in Objective-C generic arguments, so
NSArray
will get imported as
[@convention(block) (...) -> Whatever]
rather than
[(...) -> Whatever]
Fixes rdar://problem/40879067 in a fairly narrow way; the Clang
importer's approach to adjusting types based on context needs a
cleanup, but this is the safe, localized fix suitable for 4.2.