[SILGenFunction] emitBridgeErrorForForeignError hits assertion error when an `@objc` function `throws(ObjCError)`

[DataCorrupted]

Description

I noticed that swiftc can't bridge Error types between Swift and ObjC when SILGen-ing a function that explicitly throws an error bridged to ObjC. The the reproduction for an example. More specifically, the compiler crashed on the assertion:

swift/lib/SILGen/SILGenForeignError.cpp

Line 136 in e9253b7

assert(nativeErrorType == SGF.SGM.getASTContext().getErrorExistentialType());

When that assertion is hit, nativeErrorType is user defined ObjCError, while the other end is the parent classError. However, since ObjCError inherits Error, the code generated (on non-assert build) seems correct somehow.

I'd love to help fix this, if I can get some guidance in terms of how.

Reproduction

• Follow the doc to build the swift frontend first.
• Build the following code with the command:

echo "
import Foundation

@objc public enum ObjCError: Int, Error {
    case ObjCError
}

@objc class ObjCClass: NSObject {
    @objc func throwableFunc() throws(ObjCError) { return }
}
" > main.swift

../build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/bin/swiftc -emit-irgen main.swift  -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/

Stack dump

Assertion failed: (nativeErrorType == SGF.SGM.getASTContext().getErrorExistentialType()), function emitBridged, file SILGenForeignError.cpp, line 136.
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: /Users/peterrong/swift-project/build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/bin/swift-frontend -frontend -emit-irgen -primary-file main.swift -target arm64-apple-macosx15.0 -Xllvm -aarch64-use-tbi -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -color-diagnostics -Xcc -fcolor-diagnostics -empty-abi-descriptor -no-auto-bridging-header-chaining -module-name main -in-process-plugin-server-path /Users/peterrong/swift-project/build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/lib/swift/host/libSwiftInProcPluginServer.dylib -plugin-path /Users/peterrong/swift-project/build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/lib/swift/host/plugins -plugin-path /Users/peterrong/swift-project/build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/local/lib/swift/host/plugins -target-sdk-version 15.4 -target-sdk-name macosx15.4 -external-plugin-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/local/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -o -
1.      Swift version 6.2-dev (LLVM c447872d2bf1381, Swift e9253b749ff7cd4)
2.      Compiling with effective version 5.10
3.      While evaluating request ASTLoweringRequest(Lowering AST to SIL for file "main.swift")
4.      While silgen emitNativeToForeignThunk SIL function "@$s4main9ObjCClassC13throwableFunc4condACSi_tAA0B6CErrorOYKFTo".
 for 'throwableFunc(cond:)' (at main.swift:18:18)
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x000000010aaac8d4 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x000000010aaaade0 llvm::sys::RunSignalHandlers() + 112
2  swift-frontend           0x000000010aaacf2c SignalHandler(int, __siginfo*, void*) + 312
3  libsystem_platform.dylib 0x0000000190153624 _sigtramp + 56
4  libsystem_pthread.dylib  0x000000019011988c pthread_kill + 296
5  libsystem_c.dylib        0x0000000190022c60 abort + 124
6  libsystem_c.dylib        0x0000000190021eec err + 0
7  swift-frontend           0x000000010aae2f44 swift::autodiff::JVPCloner::Implementation::emitTangentForDestroyValueInst(swift::DestroyValueInst*) (.cold.1) + 0
8  swift-frontend           0x000000010584c614 (anonymous namespace)::EpilogErrorSource::emitRelease(swift::Lowering::SILGenFunction&, swift::SILLocation) const + 0
9  swift-frontend           0x000000010584b3c4 emitStoreToForeignErrorSlot(swift::Lowering::SILGenFunction&, swift::SILLocation, swift::SILValue, (anonymous namespace)::BridgedErrorSource const&) + 600
10 swift-frontend           0x000000010584b26c emitStoreToForeignErrorSlot(swift::Lowering::SILGenFunction&, swift::SILLocation, swift::SILValue, (anonymous namespace)::BridgedErrorSource const&) + 256
11 swift-frontend           0x000000010584b088 swift::Lowering::SILGenFunction::emitBridgeErrorForForeignError(swift::SILLocation, swift::SILValue, swift::SILType, swift::SILValue, swift::ForeignErrorConvention const&) + 116
12 swift-frontend           0x00000001057ee4e4 swift::Lowering::SILGenFunction::emitNativeToForeignThunk(swift::SILDeclRef) + 6720
13 swift-frontend           0x00000001057bd10c swift::Lowering::SILGenModule::emitFunctionDefinition(swift::SILDeclRef, swift::SILFunction*) + 1020
14 swift-frontend           0x00000001058bfed8 swift::Lowering::SILGenModule::emitNativeToForeignThunk(swift::SILDeclRef) + 100
15 swift-frontend           0x00000001057c0e08 swift::Lowering::SILGenModule::emitObjCMethodThunk(swift::FuncDecl*) + 156
16 swift-frontend           0x00000001058ca7e8 (anonymous namespace)::SILGenType::emitType() + 260
17 swift-frontend           0x00000001058ca6d8 swift::Lowering::SILGenModule::visitNominalTypeDecl(swift::NominalTypeDecl*) + 24
18 swift-frontend           0x00000001057c1774 swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*) + 164
19 swift-frontend           0x00000001057c1d04 swift::ASTLoweringRequest::evaluate(swift::Evaluator&, swift::ASTLoweringDescriptor) const + 608
20 swift-frontend           0x00000001058b8950 swift::SimpleRequest<swift::ASTLoweringRequest, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule>> (swift::ASTLoweringDescriptor), (swift::RequestFlags)17>::evaluateRequest(swift::ASTLoweringRequest const&, swift::Evaluator&) + 136
21 swift-frontend           0x00000001057c5644 swift::ASTLoweringRequest::OutputType swift::Evaluator::getResultUncached<swift::ASTLoweringRequest, swift::ASTLoweringRequest::OutputType swift::evaluateOrFatal<swift::ASTLoweringRequest>(swift::Evaluator&, swift::ASTLoweringRequest)::'lambda'()>(swift::ASTLoweringRequest const&, swift::ASTLoweringRequest::OutputType swift::evaluateOrFatal<swift::ASTLoweringRequest>(swift::Evaluator&, swift::ASTLoweringRequest)::'lambda'()) + 332
22 swift-frontend           0x00000001057c22a8 swift::performASTLowering(swift::FileUnit&, swift::Lowering::TypeConverter&, swift::SILOptions const&, swift::IRGenOptions const*) + 88
23 swift-frontend           0x000000010519720c swift::performCompileStepsPostSema(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 392
24 swift-frontend           0x00000001051a33ec withSemanticAnalysis(swift::CompilerInstance&, swift::FrontendObserver*, llvm::function_ref<bool (swift::CompilerInstance&)>, bool) + 164
25 swift-frontend           0x0000000105198f48 performCompile(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 536
26 swift-frontend           0x00000001051987c4 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2324
27 swift-frontend           0x0000000104f46cb4 swift::mainEntry(int, char const**) + 3108
28 dyld                     0x000000018fd7ab4c start + 6000
Abort trap: 6

Expected behavior

With no assert build, the compiler finished nicely. No miscompile observed.

Environment

Swift version 6.2-dev (LLVM c447872d2bf1381, Swift e9253b749ff7cd4)
Target: arm64-apple-macosx15.0
Build config: +assertions

Additional information

No response

[DataCorrupted]

cc @drodriguez @NuriAmari

[drodriguez]

@minuscorp @DougGregor @torstenlehmann: can you help to triage this to the appropriate person? Maybe the assert is not needed, or it is too strict?

[AdamCmiel]

The throwing annotation would only be useful for Swift type-checking do-catch blocks no? If this will always be an NSError* on the objc side then should we ignore the typed throws for objc methods or not emit the bridged method in this case? I don't see that specified in the SE https://github.com/swiftlang/swift-evolution/blob/main/proposals/0413-typed-throws.md

[DougGregor]

I think we need to ban this in the type checker, because the type has to be NSError* on the Objective-C side, and there's no good way (short of some odd as! casting) to turn that NSError* into a properly-typed error.

[DataCorrupted]

Just to clarify, "ban this" as of disallow throwing an @objc error type (NSError)?

…

On Tue, Apr 22, 2025, 12:43 PM Doug Gregor ***@***.***> wrote: I think we need to ban this in the type checker, because the type has to be NSError* on the Objective-C side, and there's no good way (short of some odd as! casting) to turn that NSError* into a properly-typed error. — Reply to this email directly, view it on GitHub <#80974 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQQFGHNKJ735JQ4XVI5EXD222LUVAVCNFSM6AAAAAB3SJTTKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRSGMYTGNZWGA> . You are receiving this because you authored the thread.Message ID: ***@***.***> *DougGregor* left a comment (swiftlang/swift#80974) <#80974 (comment)> I think we need to ban this in the type checker, because the type has to be NSError* on the Objective-C side, and there's no good way (short of some odd as! casting) to turn that NSError* into a properly-typed error. — Reply to this email directly, view it on GitHub <#80974 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQQFGHNKJ735JQ4XVI5EXD222LUVAVCNFSM6AAAAAB3SJTTKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRSGMYTGNZWGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DougGregor]

I mean that an @objc method can only throw any Error

[DataCorrupted]

That would imply @objc func foo() async throws(ObjCError) is not accepted as well, but currently the can be IRGen-ed just fine.

[DougGregor]

There are definitely issues around async as well. For example, this also causes a compiler crash:

import Foundation

@objc enum ObjCError: Int, Error {
case a
case b
}

@objc class C: NSObject {
  @objc dynamic func method() async throws(ObjCError) -> Int {
    throw ObjCError.a
  }
}


func test(c: C) async throws(ObjCError) {
  try await c.method()
}

again because when you're going through Objective-C, you have an NSError* to work with. That can always be turned into an any Error, but not necessarily a specific error.

[DataCorrupted]

That makes sense, I'll try if I can place the restriction "an @objc method can only throw any Error" during type checking.

[DougGregor]

Thanks!