Skip to content

🌸 [6.1] Work around Foundation NS_TYPED_ENUM bug #78989

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

Merged
merged 3 commits into from
Jan 29, 2025

Conversation

beccadax
Copy link
Contributor

  • Explanation: Works around a bug that affects NS_TYPED_ENUMs extended in Foundation by assuming the existence of a conformance the compiler may not have discovered yet. Without this fix, the compiler may import NS_TYPED_ENUMs without the correct bridging conformances, causing typechecking failures or compiler crashes. This change also includes compiler debugging improvements, including new PrettyStackTraces around the crash site.
  • Scope: Active only when importing NS_TYPED_ENUM types from the Foundation module.
  • Issues: rdar://142693093
  • Original PRs: Work around Foundation NS_TYPED_ENUM bug #78697
  • Risk: Low. Effects limited to Foundation.
  • Testing: Lit tests included.
  • Reviewers: @Xazax-hun

@beccadax beccadax added 🍒 release cherry pick Flag: Release branch cherry picks swift 6.1 labels Jan 28, 2025
@beccadax beccadax requested a review from a team as a code owner January 28, 2025 19:32
@beccadax
Copy link
Contributor Author

@swift-ci test

@beccadax beccadax enabled auto-merge January 28, 2025 20:51
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.
These would have helped us to debug rdar://142693093 more quickly.
@beccadax
Copy link
Contributor Author

Cleared up conflict with #78955.

@beccadax
Copy link
Contributor Author

@swift-ci please test

@beccadax beccadax merged commit 447e13b into swiftlang:release/6.1 Jan 29, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍒 release cherry pick Flag: Release branch cherry picks swift 6.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants