Possible double-destruction bug for ~Copyable type when targeting WASM

Platform Swift for WebAssembly
, , , ,
1

I’m seeing different destruction behavior for a move-only type (~Copyable) when compiling for native vs WebAssembly. Native behavior matches expectations, but the WASM build appears to destroy the value twice.


struct S: ~Copyable {
    var v: Int
    
    init(v: Int) {
        print("S init v:\(v)")
        self.v = v
    }
    deinit {
        print("S deinit v:\(v)")
    }
}
func go() {
  var s = S(v: 5)
  s.v += 1
  s.v += 1
  _ = consume s
}
go()

Native build output (expected)

S init v:5
S deinit v:7

WASM build output

S init v:5
S deinit v:5
S deinit v:7

I produced and ran the wasm build via:
swift run -c release --swift-sdk swift-6.2.4-RELEASE_wasm

Are noncopyables even supported for WASM? This seems to be a major bug

Edit: Here’s the repro in a GitHub repository GitHub - joehinkle11/WASMBug

2

Could you check what version of the compiler you're using for the native build? Just want to make sure the problem is in fact wasm-specific and not due to different compiler version bugs.

3 
swift --version
swift-driver version: 1.127.14.1 Apple Swift version 6.2.3 (swiftlang-6.2.3.3.21 clang-1700.6.3.2)
Target: arm64-apple-macosx26.0

But when I run the wasm build, I used swiftly to choose which version…

swiftly run swift --version
Apple Swift version 6.2.4 (swift-6.2.4-RELEASE)
Target: arm64-apple-macosx26.0
Build config: +assertions
1 Like
4

if you have a moment (and haven't yet done so), you should probably file a github issue for this, as it does seem like a miscompilation of some sort. FWIW disabling the dead object elimination pass (-Xllvm -sil-disable-pass=deadobject-elim) for some reason appears to prevent the issue from manifesting in this specific case (i mention this mostly out of curiosity, and doubt that it's a generally advisable workaround).

2 Likes
5

Thanks!

And here’s the issue Double-destruction bug for ~Copyable type when targeting WASM · Issue #87640 · swiftlang/swift · GitHub

3 Likes
6

Thanks! This isn't reproducible with swift-DEVELOPMENT-SNAPSHOT-2026-02-23-a, and I need to run more checks to verify with 6.3 snapshots or to find a PR/commit to cherry-pick if that's possible.

1 Like