[cxx-interop] Allow AppKit & UIKit to be rebuilt with C++ interop enabled #79822
Conversation
egorzhdan
requested review from
artemcm,
tshortli,
zoecarver,
hyp,
beccadax,
ian-twilightcoder,
Xazax-hun,
j-hui and
fahadnayyar
as code owners
|
@swift-ci please test |
There was a problem hiding this comment.
Thanks for the really clear summary of why the previous workaround was in place!
Just to make sure I understand (and because I don't think this was explicitly stated in your commit message): in addition to removing the C++ interoperability mode workaround in the module interface loader, you've also adjusted the name importing logic to account for the C/C++ discrepancy for the CF_OPTIONS and NS_OPTIONS macros, to address the specific problem that necessitated the module interface workaround in the first place. Is that correct?
egorzhdan
force-pushed
the
egorzhdan/NSUnderlineStyle
branch
from
e1e1531 to
876c00b
Compare
Yeap, exactly! |
|
@swift-ci please test |
…bled
This removes a workaround from the module interface loader, which was forcing AppKit and UIKit to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
The workaround was previously put in place because of a compiler error:
```
error: type 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute' does not conform to protocol 'AttributedStringKey'
note: possibly intended match 'AttributeScopes.AppKitAttributes.StrikethroughStyleAttribute.Value' (aka 'NSUnderlineStyle') does not conform to 'Hashable'
```
`NSUnderlineStyle` is a C/C++ type from AppKit that is declared using `NS_OPTIONS` macro. `NS_OPTIONS`/`CF_OPTIONS` macros have different expansions in C vs C++ language modes. The C++ expansions weren't handled correctly by ClangImporter, resulting in two distinct Swift types being created: a `typealias NSUnderlineStyle` which was marked as unavailable in Swift, and `enum NSUnderlineStyle`. This mostly worked fine, since the lookup logic was picking the enum during regular name lookup. However, this silently broke down when rebuilding the explicit conformance from `AppKit.swiftinterface`:
```
extension AppKit.NSUnderlineStyle : Swift.Hashable {}
```
Swift was picking the (unavailable) typealias when rebuilding this extension, which means the (available) enum wasn't getting the conformance.
This is verified by an existing test (`test/Interop/Cxx/objc-correctness/appkit-uikit.swift`).
rdar://142961112
egorzhdan
force-pushed
the
egorzhdan/NSUnderlineStyle
branch
from
876c00b to
3791ccb
Compare
|
@swift-ci please test |
|
Thank you for fixing this, Egor! |
This removes a workaround from the module interface loader, which was forcing AppKit and UIKit to be rebuilt from their textual interfaces with C++ interop disabled, even if the current compilation explicitly enables it.
The workaround was previously put in place because of a compiler error:
NSUnderlineStyleis a C/C++ type from AppKit that is declared usingNS_OPTIONSmacro.NS_OPTIONS/CF_OPTIONSmacros have different expansions in C vs C++ language modes. The C++ expansions weren't handled correctly by ClangImporter, resulting in two distinct Swift types being created: atypealias NSUnderlineStylewhich was marked as unavailable in Swift, andenum NSUnderlineStyle. This mostly worked fine, since the lookup logic was picking the enum during regular name lookup. However, this silently broke down when rebuilding the explicit conformance fromAppKit.swiftinterface:Swift was picking the (unavailable) typealias when rebuilding this extension, which means the (available) enum wasn't getting the conformance.
This is verified by an existing test (
test/Interop/Cxx/objc-correctness/appkit-uikit.swift).rdar://142961112