Compiler crash for Parameter Packs: Incorrect reconstructed type

[Kyle-Ye]

I'm adding WASM CI to some of my packages. And I noticed some Parameter Packs related compiler crash here. (The feature was introduced in Swift 5.9)

Incorrect reconstructed type for $s11OpenSwiftUI9TupleViewVyxxQp_tGD
Original type:
(bound_generic_struct_type decl=OpenSwiftUI.(file).TupleView@/home/runner/work/OpenSwiftUI/OpenSwiftUI/Sources/OpenSwiftUI/Views/View/TODO/TupleView.swift:11:15
  (tuple_type num_elements=1
    (tuple_type_elt
      (pack_expansion_type
        (pattern=generic_type_param_type depth=0 index=0 pack)
        (count=generic_type_param_type depth=0 index=0 pack)))))
Reconstructed type:
(bound_generic_struct_type decl=OpenSwiftUI.(file).TupleView@/home/runner/work/OpenSwiftUI/OpenSwiftUI/Sources/OpenSwiftUI/Views/View/TODO/TupleView.swift:11:15
  (pack_expansion_type
    (pattern=generic_type_param_type depth=0 index=0 pack)
    (count=generic_type_param_type depth=0 index=0 pack)))
Generic signature: <each τ_0_0 where repeat each τ_0_0 : View>

The reproducible code

@_disfavoredOverload
@_alwaysEmitIntoClient
public static func buildBlock<each Content>(_ content: repeat each Content) -> TupleView<(repeat each Content)> where repeat each Content: View {
    TupleView((repeat each content))
}

See full log here
https://github.com/OpenSwiftUIProject/OpenSwiftUI/actions/runs/7640702278/job/20816373359?pr=27

[kateinoigakukun]

The log URL you attached seems something different to me

[Kyle-Ye]

The log URL you attached seems something different to me

Fixed.

[Kyle-Ye]

Add more swift version for a test:

• x86_64 Ubuntu 22 + wasm-5.9.1-RELEASE ❌
• x86_64 Ubuntu 22 + wasm-5.10-SNAPSHOT-2024-01-22-a ❌
• x86_64 Ubuntu 22 + wasm-DEVELOPMENT-SNAPSHOT-2024-01-22-a ✅

[kateinoigakukun]

I think that's because we build compilers with assertions conservatively. Your code triggered ABI violation assertion, so I think it's slightly broken on other platforms as well at runtime even it passes compilation.

[Kyle-Ye]

I think that's because we build compilers with assertions conservatively. Your code triggered ABI violation assertion, so I think it's slightly broken on other platforms as well at runtime even it passes compilation.

I thought we only have stable ABI on Darwin platform 🤔.

Your code triggered ABI violation assertion

Which rule do I break? I can normally run Unit Tests target of the package on Linux, macOS and iOS. They all seem fine.

[kateinoigakukun]

It's an issue in compiler that misses type coercion for nested unpacked tuple. Please try replacing TupleView((repeat each content)) with TupleView(repeat each content).

[Kyle-Ye]

 TupleView((repeat each content))

Such code is invalid and will cause a compiler error here.

A note for the interface of TupleView

@frozen
public struct TupleView<T>: PrimitiveView {
    public var value: T
    @inlinable public init(_ value: T) { self.value = value }
    public typealias Body = Never
}

[kateinoigakukun]

Sorry, I couldn't reproduce on my end. I think disabling the assertion by adding -Xfrontend -enable-round-trip-debug-types options would be best for you. If you need more help from me, would you mind making a minimum reproducible code?

[Kyle-Ye]

-Xfrontend -enable-round-trip-debug-types

Thanks. I'll give it a try.

would you mind making a minimum reproducible code?

I believe the following snipest can reproduce it.

public protocol View {
    associatedtype Body: View
    @ViewBuilder
    @MainActor
    var body: Self.Body { get }
}

extension Never: View { public var body: Never { fatalError() } }

protocol PrimitiveView: View where Body == Never {}

extension PrimitiveView {
    public var body: Never { fatalError() }
}

@frozen
public struct TupleView<T>: PrimitiveView {
    public var value: T
    @inlinable public init(_ value: T) { self.value = value }
    public typealias Body = Never
}

@resultBuilder
public enum ViewBuilder {
    @_alwaysEmitIntoClient
    public static func buildExpression<Content>(_ content: Content) -> Content where Content: View {
        content
    }

    @_alwaysEmitIntoClient
    public static func buildBlock<Content>(_ content: Content) -> Content where Content: View {
        content
    }

    @_disfavoredOverload
    @_alwaysEmitIntoClient
    public static func buildBlock<each Content>(_ content: repeat each Content) -> TupleView < (repeat each Content)> where repeat each Content: View {
        TupleView((repeat each content))
    }
}

[kateinoigakukun]

Thanks, but it doesn't reproduce. Please ensure that swiftc -frontend -c check.swift -target wasm32-unknown-wasi can reproduce it.

[Kyle-Ye]

Thanks, but it doesn't reproduce. Please ensure that swiftc -frontend -c check.swift -target wasm32-unknown-wasi can reproduce it.

Haven't installed Wasm Swift SDK locally before. I'll give it a shot this weekend and report the minimum reproducible code later.

[Kyle-Ye]

Add more swift version for a test:

• x86_64 Ubuntu 22 + wasm-5.9.1-RELEASE ❌
• x86_64 Ubuntu 22 + wasm-5.10-SNAPSHOT-2024-01-22-a ❌
• x86_64 Ubuntu 22 + wasm-DEVELOPMENT-SNAPSHOT-2024-01-22-a ✅

1. Using a local wasm-5.9.1-RELEASE SDK + Xcode 15.2 gives more error here

Building for debugging...
/Applications/Xcode-15.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks/Foundation.framework/Modules/Foundation.swiftmodule/arm64e-apple-macos.swiftinterface:3944:141: error: cannot specialize non-generic type 'Collection' (aka 'OpaquePointer')
  public mutating func replaceSubrange(_ subrange: Swift.Range<Foundation.AttributedString.UnicodeScalarView.Index>, with newElements: some Collection<UnicodeScalar>)
                                                                                                                                            ^         ~~~~~~~~~~~~~~~

/Applications/Xcode-15.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/Library/Frameworks/Foundation.framework/Modules/Foundation.swiftmodule/arm64e-apple-macos.swiftinterface:11963:137: error: cannot specialize non-generic type 'Collection' (aka 'OpaquePointer')
  public mutating func replaceSubrange(_ subrange: Swift.Range<Foundation.AttributedString.CharacterView.Index>, with newElements: some Collection<Character>)
                                                                                                                                        ^         ~~~~~~~~~~~

/Applications/Xcode-15.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/lib/swift/OSLog.swiftmodule/arm64e-apple-macos.swiftinterface:5:8: error: failed to build module 'Foundation'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.9.2 (swiftlang-5.9.2.2.11 clang-1500.1.0.2.2)', while this compiler is 'SwiftWasm Swift version 5.9.1 (swift-5.9.1-RELEASE)'). Please select a toolchain which matches the SDK.
import Foundation

This compile error would be fixed in Swift 5.9.2

2. Using a local wasm-5.10-SNAPSHOT-2024-01-22-a SDK + Xcode 15.2 works fine and can not reproduce the issue.

• arm64 macOS 14 + Xcode 14.2 + wasm-5.10-SNAPSHOT-2024-01-22-a ✅

I'd like to try the same env of the CI - Ubuntu 22 here. But my Linux env is aarch64 Ubuntu 22 and there is no such wasm SDK to download currently.

I'll set up a x86_64 Ubuntu 22 to give it a try.

[Kyle-Ye]

Thanks, but it doesn't reproduce. Please ensure that swiftc -frontend -c check.swift -target wasm32-unknown-wasi can reproduce it.

Set up a x86_64 Ubuntu 22 locally and I can reproduce the bug both with OpenSwiftUI package and the snippets package I post above with swift build command (The same command I'm using for CI).

DemoKit.zip

Using swiftc -frontend -c check.swift -target wasm32-unknown-wasi gives a warning here and give a .o output as success. Do you know what should I do to make swift build also success here?

kyle@ubuntu-amd64:/DemoKit/Sources/DemoKit$ swift --version
SwiftWasm Swift version 5.9.1 (swift-5.9.1-RELEASE)
Target: x86_64-unknown-linux-gnu
kyle@ubuntu-amd64:/DemoKit/Sources/DemoKit$ swiftc -frontend -c DemoKit.swift -target wasm32-unknown-wasi
<unknown>:0: warning: glibc not found for 'wasm32-unknown-wasi'; C stdlib may be unavailable
kyle@ubuntu-amd64:/DemoKit/Sources/DemoKit$ l
DemoKit.o  DemoKit.swift

In summary, the current build matrix:

// `swift build` result for DemoKit package
x86_64 Ubuntu 22 + wasm-5.9.1-RELEASE ❌
x86_64 Ubuntu 22 + wasm-5.10-SNAPSHOT-2024-01-22-a ❌
x86_64 Ubuntu 22 + wasm-DEVELOPMENT-SNAPSHOT-2024-01-22-a ✅
arm64 macOS 14 + Xcode 14.2 + wasm-5.9.1-RELEASE ❓ (Blocked by other issue waiting for a wasm-5.9.2-RELEASE)
arm64 macOS 14 + Xcode 14.2 + wasm-5.10-SNAPSHOT-2024-01-22-a ✅

On my side, I'm consider using macOS container as CI or use the latest wasm-DEVELOPMENT-SNAPSHOT + Ubuntu as a workaround while waiting for a upstream investigation.

[kateinoigakukun]

At this moment, please use swift build -Xswiftc -Xfrontend -Xswiftc -disable-round-trip-debug-types. The root issue is an upstream compiler bug and it's not completely related to Wasm target. Also it's already fixed in main branch.

[Kyle-Ye]

At this moment, please use swift build -Xswiftc -Xfrontend -Xswiftc -disable-round-trip-debug-types. The root issue is an upstream compiler bug and it's not completely related to Wasm target. Also it's already fixed in main branch.

Thanks. It works. I'll update my CI script to fix it.