Work around Foundation NS_TYPED_ENUM bug #78697
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
beccadax
requested review from
zoecarver,
hyp,
egorzhdan,
ian-twilightcoder,
Xazax-hun,
hborla,
slavapestov and
xedin
as code owners
|
Will look into adding a unit test shortly. |
|
@swift-ci please smoke test |
beccadax
force-pushed
the
rdar142693093
branch
from
d53515f to
83123df
Compare
|
@swift-ci please smoke test |
|
Do we have a plan how to fix this issue properly in the future? Is there a ticket to track that? |
beccadax
force-pushed
the
rdar142693093
branch
from
83123df to
d749405
Compare
Consider code like:
```
// Foo.h
typealias NSString * FooKey NS_EXTENSIBLE_TYPED_ENUM;
// Foo.swift
extension FooKey { … }
```
When Swift binds the extension to `FooKey`, that forces ClangImporter to import `FooKey`. ClangImporter’s newtype logic, among other things, checks whether the underlying type (`Swift.String` here) is Objective-C bridgeable and, if so, makes `FooKey` bridgeable too.
But what happens if this code is actually *in* Foundation, which is where the `extension String: _ObjectiveCBridgeable` lives? Well, if the compiler has already bound that extension, it works fine…but if it hasn’t, `FooKey` ends up unbridgeable, which can cause both type checking failures and IRGen crashes when code tries to use its bridging capabilities. And these symptoms are sensitive to precise details of the order Swift happens to bind extensions in, so e.g. adding empty files to the project can make the bug appear or disappear. Spooky.
Add a narrow hack to ClangImporter (only active for types in Foundation) to *assume* that `String` is bridgeable even if the extension declaring this hasn’t been bound yet.
Fixes rdar://142693093.
|
@Xazax-hun Filed as #78731, though there is no specific timeline for when this work might be carried out. In practice, the vast majority of projects are not supposed to be declaring |
beccadax
force-pushed
the
rdar142693093
branch
from
d749405 to
56b2035
Compare
|
@swift-ci please smoke test |
Xazax-hun
approved these changes
Jan 20, 2025
I see, thanks! |
|
@swift-ci please smoke test |
These would have helped us to debug rdar://142693093 more quickly.
|
Build wrangler has disabled the failing Linux test. |
|
@swift-ci please smoke test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider code like:
When Swift binds the extension to
FooKey, that forces ClangImporter to importFooKey. ClangImporter’s newtype logic, among other things, checks whether the underlying type (Swift.Stringhere) is Objective-C bridgeable and, if so, makesFooKeybridgeable too.But what happens if this code is actually in Foundation, which is where the
extension String: _ObjectiveCBridgeablelives? Well, if the compiler has already bound that extension, it works fine…but if it hasn’t,FooKeyends up unbridgeable, which can cause both type checking failures and IRGen crashes when code tries to use its bridging capabilities. And these symptoms are sensitive to precise details of the order Swift happens to bind extensions in, so e.g. adding empty files to the project can make the bug appear or disappear. Spooky.Add a narrow hack to ClangImporter (only active when we are compiling Foundation) to assume that
Stringis bridgeable even if the extension declaring this hasn’t been bound yet.This PR also incorporates minor improvements to type dumping that I added while debugging this issue.
Fixes rdar://142693093.