Time Change: -9,130.25ms (2149%) 🏆

Total Time: 424.75ms

_{performance-action}

I'm seeing consistent errors with the latest SwiftWasm 5.6 snapshot:

TypeError: Cannot read properties of undefined (reading 'buffer')

any ideas?

I can easily reproduce on macOS 12, not sure how the test passed.
Investigating the issue, for now findings are it's coming from swift.setInstance causing Swift error:

JavaScriptKit/JSClosure.swift:138: Fatal error: The function was already released

(Guessing it's more of a function not found issue than released?)

I guess this is due to the introduction of the reactor model in WASI and wasi-libc. See WebAssembly/WASI#13

This means we need to build Swift executable with reactor model when using JSKit because our runtime calls some exported functions multiple times.

@kateinoigakukun wouldn't libc changes be in the toolchain?
I now cannot get carton/JSKit (from main) to work at all (similar issues to this), but I'm using swift-wasm-5.6-SNAPSHOT-2022-03-23-a toolchain which was working fine with previous carton/JSKit. I also don't see JS wasmer version change, so can't figure it out.

@yonihemi I recently updated wasi-sdk including wasi-libc swiftwasm/swift#4360 and backported it to 5.6 branch. Here is a minimum patch to pass the integration tests https://github.com/swiftwasm/JavaScriptKit/compare/katei/try-reactor-model but we have to think about how to pass -mexec-model=reactor when building.

Would passing -mexec-model=reactor in carton be sufficient, or do you prefer some other way to pass it?

@MaxDesiatov I think it would be sufficient for most use cases, but I may overlook something...
Anyway, it's OK to pass the flag in IntegrationTests/Makefile for now.

It's a bit unclear to me how this option should be passed to swift build. I've tried all the different combinations, including -Xswiftc -Xclang-linker -mexec-model=reactor, which leads to error: Unknown option '-mexec-model', as the rest of the combinations did.

I wonder if having these flags in Package.swift, like in your branch, is a better approach?

@MaxDesiatov -Xswiftc -Xclang-linker -Xswiftc -mexec-model=reactor is the correct combination

Oh dear 😅

CI is green. After testing with Tokamak, I think it's time to tag SwiftWasm 5.6.0 and then update this PR for that release. Any objections?

Something's broken in distribute-latest-toolchain.sh I guess? For some reason wasm-5.6.0-RELEASE.pkg is unpacked to /Library/Developer/Toolchains/swift-wasm-5.6-SNAPSHOT-2022-04-01-a.xctoolchain instead of /Library/Developer/Toolchains/swift-wasm-5.6.0-RELEASE.xctoolchain as we'd expect, even though I've specified same distribution workflow parameters as I did for 5.5.0. This is the reason for latest CI failure on this PR.

I'm not 100% sure if swiftwasm/swift@3be7ec1 had any impact, but that's the only recent change in that script that I see.

I don't have more time to look into this either today or even this weekend, sorry. Maybe next week. If anyone can pick this up in the meantime, I'd greatly appreciate it. As usual, no need to rush, I'm happy to delay 5.6.0 for whatever time it takes to make it work.

BTW, these are the settings that I use for each release, just swapping patch and date numbers in it. I'm keeping this screenshot for reference, but I guess it's time to create a release process document and attach it there 😅

@MaxDesiatov That's my bad 🤦 I've fixed it now swiftwasm/swift@b36d317

ok, I'll kick off new manual distribution then