# Can we get consistent assertion behavior in the latest release Swift compiler across host platforms? **URL:** \ **Category:** Compiler\ **Tags:** assertions\ **Created:** [June 18, 2025, 7:25pm UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545 "2025-06-18T19:25:44Z")\ **Posts on this page:** 9\ **Page:** 2
**Author:** ![Torust](https://avatars.discourse-cdn.com/v4/letter/t/f17d59/32.png) [@Torust](https://forums.swift.org/u/Torust)\ **Post date:** [December 28, 2025, 9:09am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/21 "2025-12-28T09:09:18Z")
In my opinion, the right behaviour here is that development snapshots should have assertions enabled and official point releases should have them disabled across all platforms; this is how it effectively works on macOS (the official Xcode toolchain, which most macOS developers use, is assertions disabled; [Swift.org](http://Swift.org) snapshots are assertions enabled). If you’re downloading a development snapshot you’re expecting less stability, and if you’re on a release compiler you expect it to be stable and as fast as possible (since assertions carry some runtime overhead). It would be nice if the Windows toolchains could align with this pattern. ---
**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\ **Post date:** [December 28, 2025, 10:14am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/22 "2025-12-28T10:14:47Z")
> [@compnerd](#): > > At least for Windows, the default is the asserting toolchain. Sadly, adding the no asserts toolchain is quite expensive (adding an additional ~1.5h and increasing the installer by an additional ~500MB). Might be worth considering here: have an extra conditional variable (environment variable?) that controls whether assert crashes or not (or equally make `assert` a function pointer that points to either normal assert implementation or another implementation that doesn't crash, just logs). The conditional variable / function pointer will be set early and never changed again to simplify thread safety angle. * * * Test implementation: ```swift private let trappingAssert = ProcessInfo.processInfo.environment["DONT_TRAP_ON_ASSERTS"] != "1" public func assert(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String(), file: StaticString = #fileID, line: UInt = #line) { if !condition() { print("\(file): \(line) \(message())") // log, etc if trappingAssert { _real_assert(false) // underlying assert } } } ``` ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [December 29, 2025, 2:09am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/23 "2025-12-29T02:09:55Z")
> [@Torust](#): > > It would be nice if the Windows toolchains could align with this pattern. Unfortunately, we don't have enough code to throw at the compiler to ensure correctness. On macOS and Linux, the regular validation will force a significant amount of code to be compiled with the compiler to help find issues. I barely got ~2 reports of issues with the new support for static linking, with the remainder of the issues being found by me later during use. I would say that Windows currently has no viable path to align with this and should remain assertions only. The middle ground approach would be to bundle an additional NoAsserts toolchain that the user is able to opt-in to. But, I don't think that would be reasonable to do without some additional work to improve the infrastructure to support that. This does work well enough in practice - the BCNY toolchains do this - and still default to the Asserts variant. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [December 30, 2025, 2:14pm UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/24 "2025-12-30T14:14:43Z")
What's the right way to bring this more officially to the [@platform-steering-group](https://forums.swift.org/groups/platform-steering-group) to get an official word? I appreciate we as individuals have opinions, but it'd be good, considering how it's affecting real-world maintenance of packages in the wild, for this to be discussed and driven to resolution by the right entities in the Swift project. Maybe the [@ecosystem-steering-group](https://forums.swift.org/groups/ecosystem-steering-group) should also chime in, since this is a usability pain. ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [December 31, 2025, 12:36am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/25 "2025-12-31T00:36:35Z")
> [@Honza\_Dvorsky](#): > > Maybe the [@ecosystem-steering-group](https://forums.swift.org/groups/ecosystem-steering-group) should also chime in, since this is a usability pain. IMO this is more for the PSG than the ESG as it pertains to the details of the platform. While I can appreciate that the platforms impact the ecosystem (Windows not being supported would be a massive hit to the ecosystem), this is really a PSG issue IMO. We can certainly put this on the PSG backlog though. ---
**Author:** ![woody\_melling](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/woody_melling/32/36190_2.png) [@woody\_melling](https://forums.swift.org/u/woody_melling)\ **Post date:** [January 21, 2026, 8:03pm UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/26 "2026-01-21T20:03:46Z")
> [@compnerd](#): > > If this is for CI/CD purposes, perhaps adopting the OSS toolchain on Darwin might be an option to consider. The OSS Darwin toolchain has these assertions enabled. If I install Swift on my computer using swiftly, there are dozens of populat packages that have crashed the compiler for a year, due to running into assertions. As an application developer thats sharing code across multiple platforms, this issue causes a ton of headaches. Not only do I have to be careful not to introduce code that will crash the compiler, I also can’t use libraries that trip these assertions. And bitrot is always on the horizon, if any of my dependencies introduce perfectly valid swift code, I have to pin it and no longer receive updates to that library. Is there anything we can do to get this moving through the [@platform-steering-group](https://forums.swift.org/groups/platform-steering-group)? This bug has some minimum reproducable code in it surrounding parameter packs. > > > \### Description > > When attempting to build the parameter pack code in Reproductio…n, the Swift 6.0.3 OSS toolchain (\`~/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/bin/swift build)\` crashes, but the Swift 6.0.3 toolchain bundled with Xcode 16.2 (\`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift build\`) builds fine. > > Likely related to https://github.com/swiftlang/swift/issues/78693 and https://github.com/swiftlang/swift/issues/78671. > > This was reported on our Slack (https://skiptools.slack.com/archives/C07MLMD57ST/p1741494643312329) when building for Android, which uses the OSS host toolchain. > > \### Reproduction > > \`\`\`swift > // RUN: %target-swift-frontend -emit-silgen %s -verify -o /dev/null > > public struct TupleComponent\: Component { > public func write(\_ data: (repeat (each T).Content)) { } > } > > public protocol Component\ { > associatedtype Content > func write(\_ data: Content) > } > \`\`\` > > > \### Stack dump > > \`\`\`text > error: emit-module command failed due to signal 6 (use -v to see invocation) > Assertion failed: (isLValue() && "This isn't an lvalue"), function getLValueAddress, file ManagedValue.h, line 318. > Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace. > Stack dump: > 0. Program arguments: /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/bin/swift-frontend -frontend -emit-module -experimental-skip-non-inlinable-function-bodies-without-types /private/tmp/TupleDemo/Sources/TupleDemo/TupleDemo.swift -target arm64-apple-macosx10.13 -Xllvm -aarch64-use-tbi -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -I /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/Modules -I /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/lib/swift/macosx/testing -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -color-diagnostics -enable-testing -g -debug-info-format=dwarf -dwarf-version=4 -module-cache-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/ModuleCache -swift-version 6 -Onone -D SWIFT\_PACKAGE -D DEBUG -empty-abi-descriptor -plugin-path /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/lib/swift/host/plugins/testing -resource-dir /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/lib/swift -enable-anonymous-context-mangled-names -file-compilation-dir /private/tmp/TupleDemo -Xcc -isysroot -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -Xcc -F -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -Xcc -fPIC -Xcc -g -module-name TupleDemo -package-name tupledemo -plugin-path /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Users/marc/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/local/lib/swift/host/plugins -target-sdk-version 15.2 -target-sdk-name macosx15.2 -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 -emit-module-doc-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/Modules/TupleDemo.swiftdoc -emit-module-source-info-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/Modules/TupleDemo.swiftsourceinfo -emit-objc-header-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/TupleDemo.build/TupleDemo-Swift.h -emit-dependencies-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/TupleDemo.build/TupleDemo.emit-module.d -parse-as-library -o /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/Modules/TupleDemo.swiftmodule -emit-abi-descriptor-path /private/tmp/TupleDemo/.build/arm64-apple-macosx/debug/Modules/TupleDemo.abi.json > 1. Apple Swift version 6.0.3 (swift-6.0.3-RELEASE) > 2. Compiling with the current language version > 3. While evaluating request ASTLoweringRequest(Lowering AST to SIL for module TupleDemo) > 4. While generating SIL witness table protocol conformance TupleComponent\: Component at 'TupleComponent' (at /private/tmp/TupleDemo/Sources/TupleDemo/TupleDemo.swift:5:8) > 5. While generating protocol witness thunk SIL function "@$s9TupleDemo0A9ComponentVyxxQp\_QPGAA0C0A2aEP5writeyy7ContentQzFTW". > for 'write(\_:)' (at /private/tmp/TupleDemo/Sources/TupleDemo/TupleDemo.swift:6:12) > 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 0x0000000107db80f8 llvm::sys::PrintStackTrace(llvm::raw\_ostream&, int) + 56 > 1 swift-frontend 0x0000000107db68c4 llvm::sys::RunSignalHandlers() + 112 > 2 swift-frontend 0x0000000107db8740 SignalHandler(int) + 304 > 3 libsystem\_platform.dylib 0x000000018c18ede4 \_sigtramp + 56 > 4 libsystem\_pthread.dylib 0x000000018c157f70 pthread\_kill + 288 > 5 libsystem\_c.dylib 0x000000018c064908 abort + 128 > 6 libsystem\_c.dylib 0x000000018c063c1c err + 0 > 7 swift-frontend 0x0000000107ef6244 (anonymous namespace)::TranslateArguments::expandSingleOuterInnerTuple(swift::Lowering::AbstractionPattern, swift::CanTypeWrapper\, swift::Lowering::AbstractionPattern, swift::CanTypeWrapper\, swift::Lowering::ManagedValue) (.cold.35) + 0 > 8 swift-frontend 0x0000000102fd4b28 (anonymous namespace)::TranslateArguments::expandSingleOuterInnerTuple(swift::Lowering::AbstractionPattern, swift::CanTypeWrapper\, swift::Lowering::AbstractionPattern, swift::CanTypeWrapper\, swift::Lowering::ManagedValue) + 1876 > 9 swift-frontend 0x0000000102fd2680 (anonymous namespace)::ExpanderBase\<(anonymous namespace)::TranslateArguments, (anonymous namespace)::ParamInfo\>::expand(swift::Lowering::AbstractionPattern, swift::CanType, swift::Lowering::AbstractionPattern, swift::CanType) + 616 > 10 swift-frontend 0x0000000102fd8c24 (anonymous namespace)::TranslateArguments::expandParam(swift::Lowering::AbstractionPattern, swift::AnyFunctionType::CanParam, swift::Lowering::AbstractionPattern, swift::AnyFunctionType::CanParam) + 224 > 11 swift-frontend 0x0000000102fcbc08 (anonymous namespace)::TranslateArguments::process(swift::Lowering::AbstractionPattern, swift::ArrayRefView\, swift::Lowering::AbstractionPattern, swift::ArrayRefView\, bool) + 2992 > 12 swift-frontend 0x0000000102fce160 swift::Lowering::SILGenFunction::emitProtocolWitness(swift::Lowering::AbstractionPattern, swift::CanTypeWrapper\, swift::SILDeclRef, swift::SubstitutionMap, swift::SILDeclRef, swift::SubstitutionMap, swift::Lowering::IsFreeFunctionWitness\_t, bool, bool, std::\_\_1::optional\) + 2576 > 13 swift-frontend 0x0000000102ffa7c4 swift::Lowering::SILGenModule::emitProtocolWitness(swift::ProtocolConformanceRef, swift::SILLinkage, swift::SerializedKind\_t, swift::SILDeclRef, swift::SILDeclRef, swift::Lowering::IsFreeFunctionWitness\_t, swift::Witness) + 2992 > 14 swift-frontend 0x0000000102ffced0 (anonymous namespace)::SILGenWitnessTable\<(anonymous namespace)::SILGenConformance\>::addMethodImplementation(swift::SILDeclRef, swift::SILDeclRef, swift::Witness) + 528 > 15 swift-frontend 0x0000000102ffc848 (anonymous namespace)::SILGenWitnessTable\<(anonymous namespace)::SILGenConformance\>::addMethod(swift::SILDeclRef) + 532 > 16 swift-frontend 0x0000000102ffc398 swift::SILWitnessVisitor\<(anonymous namespace)::SILGenConformance\>::visitProtocolDecl(swift::ProtocolDecl\*) + 1992 > 17 swift-frontend 0x0000000102ff9aa4 swift::Lowering::SILGenModule::getWitnessTable(swift::NormalProtocolConformance\*) + 324 > 18 swift-frontend 0x0000000102ffb878 (anonymous namespace)::SILGenType::emitType() + 1580 > 19 swift-frontend 0x0000000102ffb240 swift::Lowering::SILGenModule::visitNominalTypeDecl(swift::NominalTypeDecl\*) + 24 > 20 swift-frontend 0x0000000102eeb448 swift::ASTLoweringRequest::evaluate(swift::Evaluator&, swift::ASTLoweringDescriptor) const + 880 > 21 swift-frontend 0x0000000102fe90a4 swift::SimpleRequest\\> (swift::ASTLoweringDescriptor), (swift::RequestFlags)9\>::evaluateRequest(swift::ASTLoweringRequest const&, swift::Evaluator&) + 148 > 22 swift-frontend 0x0000000102ef0d24 swift::ASTLoweringRequest::OutputType swift::Evaluator::getResultUncached\(swift::Evaluator&, swift::ASTLoweringRequest)::'lambda'()\>(swift::ASTLoweringRequest const&, swift::ASTLoweringRequest::OutputType swift::evaluateOrFatal\(swift::Evaluator&, swift::ASTLoweringRequest)::'lambda'()) + 340 > 23 swift-frontend 0x0000000102eeba7c swift::performASTLowering(swift::ModuleDecl\*, swift::Lowering::TypeConverter&, swift::SILOptions const&, swift::IRGenOptions const\*) + 144 > 24 swift-frontend 0x00000001028ce358 swift::performCompileStepsPostSema(swift::CompilerInstance&, int&, swift::FrontendObserver\*) + 1176 > 25 swift-frontend 0x00000001028d9e5c withSemanticAnalysis(swift::CompilerInstance&, swift::FrontendObserver\*, llvm::function\_ref\, bool) + 160 > 26 swift-frontend 0x00000001028d0028 performCompile(swift::CompilerInstance&, int&, swift::FrontendObserver\*) + 708 > 27 swift-frontend 0x00000001028cf6fc swift::performFrontend(llvm::ArrayRef\, char const\*, void\*, swift::FrontendObserver\*) + 2344 > 28 swift-frontend 0x00000001026e5edc swift::mainEntry(int, char const\*\*) + 3096 > 29 dyld 0x000000018bdd8274 start + 2840 > \`\`\` > > \### Expected behavior > > The OSS toolchain should compile the code without crashing just like the Xcode toolchain does. > > \### Environment > > \`\`\` > zap /tmp/TupleDemo % ~/Library/Developer/Toolchains/swift-6.0.3-RELEASE.xctoolchain/usr/bin/swift -version > Apple Swift version 6.0.3 (swift-6.0.3-RELEASE) > Target: arm64-apple-macosx15.0 > > zap /tmp/TupleDemo % /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -version > swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1) > Target: arm64-apple-macosx15.0 > > zap /tmp/TupleDemo % sw\_vers > ProductName: macOS > ProductVersion: 15.3.1 > BuildVersion: 24D70 > > Xcode: Version 16.2 (16C5032a) > > \`\`\` > > \### Additional information > > \_No response\_ ---
**Author:** ![dmitri](https://avatars.discourse-cdn.com/v4/letter/d/b9bd4f/32.png) [@dmitri](https://forums.swift.org/u/dmitri)\ **Post date:** [February 19, 2026, 1:21am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/27 "2026-02-19T01:21:23Z")
I ran into a similar situation with this small piece of code: on Xcode built-in and Linux (swift 6.2+ toolchains) the code compiles fine, while on downloaded open-sourced macOS toolchains it fires the asserts (e.g. `Assertion failed: (claimed.size() == primaryAssociatedTypes.size()), function createConstrainedExistentialType at ASTDemangler.cpp:85`, with `swift-6.2.3-RELEASE.xctoolchain` ) ```swift typealias FullProtocolWithU = FullProtocol & ProtocolGenericU typealias FullProtocolWithT = FullProtocol & ProtocolGenericT protocol FullProtocol: ProtocolGenericU, ProtocolGenericT {} protocol ProtocolGenericU: BaseProtocol {} protocol ProtocolGenericT: BaseProtocol {} protocol BaseProtocol { associatedtype U associatedtype T var t: T { get } } struct S: FullProtocol { typealias U = Double typealias T = Int let t = 1 } func crashOpenSourceSwift6_2_MacOS_Toolchain(_ value: any FullProtocolWithT) { print("Here's the T: ", value.t) } let value = S() crashOpenSourceSwift6_2_MacOS_Toolchain(value) ``` I want to use this pattern so that I can conform my types to just one protocol (`FullProtocol`) and then in some existential contexts require only the type `U` to be constrained, in other existential contexts, only require the type `T` to be constrained, and in some existential context require both `U` and `T` to be constrained. This compiles and works without issue on Linux, macOS, and iOS, with swift 6.2+, provided that I'm not using the open-source toolchains on macOS. ---
**Author:** ![Finagolfin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/finagolfin/32/34388_2.png) [@Finagolfin](https://forums.swift.org/u/Finagolfin)\ **Post date:** [May 11, 2026, 3:54am UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/28 "2026-05-11T03:54:44Z")
It appears this has been fixed for the OSS macOS release toolchain, which now turns off assertions too: ```swift > swiftly list Installed release toolchains ---------------------------- Swift 6.3.1 (in use) (default) Swift 6.2.4 -- snip --- > swift -version Apple Swift version 6.3.1 (swift-6.3.1-RELEASE) Target: arm64-apple-macosx26.0 ``` Trying it out with [a recent SIL assertion crasher reported on GitHub](https://github.com/swiftlang/swift/issues/88455) causes no problems, whereas it would crash the prior 6.2.4 release with assertions enabled: ```swift >swift prop.swift > swiftly use 6.2.4 The global default toolchain has been set to `Swift 6.2.4` (was 6.3.1) > swift -version Apple Swift version 6.2.4 (swift-6.2.4-RELEASE) Target: arm64-apple-macosx26.0 Build config: +assertions > swift prop.swift Assertion failed: ((AccessKind == SGFAccessKind::BorrowedObjectRead || AccessKind == SGFAccessKind::BorrowedAddressRead) && "non-borrow component requires an address base"), function emitUsingStorage, file SILGenLValue.cpp, line 3497. ``` Thanks to the Swift team for changing this; the only remaining outlier is the Windows release toolchain, which I think still has asserts enabled. ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [May 11, 2026, 2:17pm UTC](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545/29 "2026-05-11T14:17:31Z")
Windows ships both variants, encourages the use of the assets toolchain, but allows you to opt into the noasserts build. We still require that issues being filed use the asserts toolchain. [Previous page](https://forums.swift.org/t/can-we-get-consistent-assertion-behavior-in-the-latest-release-swift-compiler-across-host-platforms/80545.md?page=1)