SwiftWasm 5.3.0 release checklist

[MaxDesiatov]

These are the things that would be great to see before SwiftWasm 5.3.0 is tagged:

• Re-enable stdlib test suite on CI for at least macOS in swiftwasm-release/5.3 branch, ideally on Linux too (it currently fails, but CI passes anyway). If this is blocked by Wasmer, we need to report this issue to them and link it here.
• Rename Glibc module to WASI in SwiftWasm 5.3 snapshots (tracked in Add WASI module to use instead of Glibc #196, fixed in Add WASI module to replace Glibc on WASI platform #1773 for swiftwasm-release/5.3 and in WASILibc module for main stream #1832 for swiftwasm)
• Fix linking issues in test targets (tracked in Building a test bundle fails with 5.3 snapshots #1824).
• Fix linker warnings in 5.3 toolchains (tracked in Linker warnings when building with the new 5.3 toolchain #1823).
• Add a guide for carton usage to the SwiftWasm book.
• Allow building JavaScriptKit without unsafe flags in its Package.swift (tracked in Build fails with the unsafe flags error JavaScriptKit#6)
• Ship working IndexStore in SwiftWasm 5.3 snapshots to allow swift test --enable-test-discovery (done in Install sourcekit-lsp #1845 and Ship IndexStore and SourceKit-LSP in 5.3 snapshots #1851)
• Ship SourceKit-LSP in SwiftWasm 5.3 snapshots (done in Install sourcekit-lsp #1845 and Ship IndexStore and SourceKit-LSP in 5.3 snapshots #1851)
• Fix missing Info.plist warning (tracked in Xcode warnings after installing .pkg toolchains #2072).
• Patch SourceKit-LSP to allow --destination option to be passed to it (tracked in Add --destination option to SourceKit-LSP to use for indexing #1935)
• Attempt integrating new LTO into swiftwasm-release/5.3 branch? I'm probably fine releasing 5.3.0 without it.

As usual, feedback is welcome. Lmk if you see anything's missing, but also bear in mind that the upstream 5.3.0 is going to be released very soon, almost certainly with iOS 14, so this list can't grow much more.

[kateinoigakukun]

Re-enable stdlib test suite on CI for at least macOS in swiftwasm-release/5.3 branch, ideally on Linux too (it currently fails, but CI passes anyway)

I think the stdlib test suites are running on macOS CI now.

Rename Glibc module to WASI in SwiftWasm 5.3 snapshots (tracked in #196, WIP in #1685)

I'll do this for 5.3 branch

Ship working IndexStore in SwiftWasm 5.3 snapshots to allow swift test --enable-test-discovery (WIP in #1496)

I'll take a look again for the failure reason

Attempt integrating new LTO into swiftwasm-release/5.3 branch? I'm probably fine releasing 5.3.0 without it.

I think it's too hard to integrate it with 5.3 branch at this time. I need to resolve conflict between 5.3 and master

[MaxDesiatov]

I've checked the latest 5.3 run on macOS and there are no test results in the logs, even though it seems like it attempts to build the stdlib unittest target. 🤔

[kateinoigakukun]

2020-09-25T16:41:44.1534080Z 5 warning(s) in tests
2020-09-25T16:41:44.1690960Z 
2020-09-25T16:41:44.1691620Z Testing Time: 663.31s
2020-09-25T16:41:44.1691900Z   Expected Passes    : 111
2020-09-25T16:41:44.1692190Z   Expected Failures  : 2
2020-09-25T16:41:44.1693490Z   Unsupported Tests  : 108

stdlib tests were done on CI but swift-test-results.tar.gz doesn't contain any result.

[kateinoigakukun]

Before releasing 5.3, I'll add additional configuration to publish toolchain as signed and installable via pkg installer.

[MaxDesiatov]

Awesome, thank you for taking care of this!

[MaxDesiatov]

@swiftwasm/swiftwasm-team looks like swift-wasm-5.3-SNAPSHOT-2020-10-20-a is our 5.3.0 release candidate, WDYT? Have you seen any issues with this toolchain or any other recent snapshots?

[kateinoigakukun]

I want to include #2054 also.

[MaxDesiatov]

Right, it was supposed to be included in 2020-10-21, but the nightly distribution script failed with The job running on runner GitHub Actions 3 has exceeded the maximum execution time of 360 minutes. As you have the signing assets, could you tag that snapshot one last time? We could look at the distribution/signing script later after 5.3.0 is released.

[kateinoigakukun]

Yes, the distribution script failed and I'm debugging it. OK, I'll publish today's toolchain from my local machine.

[MaxDesiatov]

Thanks, I appreciate it! Now that wasm-5.3-SNAPSHOT-2020-10-21-a is tagged, let's use that for a week and tag it as 5.3.0 after that if there are no issues or objections by then.

[MaxDesiatov]

Discovered a new bug #2072. Would be great to fix, I've added it to the checklist.

[kateinoigakukun]

@swiftwasm/swiftwasm-team
Some essential changes are now landed on swiftwasm-release/5.3 branch.

• Fix Info.plist location and bug report url for 5.3 release branch #2075
• Remove sed backup file from toolchain for 5.3 branch #2083
• Set default sdk value as wasi-sysroot when targeting WASI OS for 5.3 #2096
• Propagate -use-static-resource-dir for merge-module for 5.3 #2098
• Fix postinstall script for 5.3 #2099

I think swift-wasm-5.3-SNAPSHOT-2020-10-26-a is a latest release candidate for 5.3. I'll test the toolchain in this week, and if there is no big issue, I want to tag it as 5.3-RELEASE.

[MaxDesiatov]

I've pushed a change to SwiftPM in the 5.3 branch to use .wasm as the default extension for produced Wasm binaries yesterday. I'm not seeing it in swift-wasm-5.3-SNAPSHOT-2020-10-27-a, which was tagged last night, investigating why. I hope we can squeeze that change in, as making it after the release would be far more disruptive I think.

[kateinoigakukun]

@MaxDesiatov Did you trigger swiftwasm/swift CI after merging SwiftPM change? I think we need to trigger again for 5.3 branch.

[MaxDesiatov]

Yes, I did trigger it in https://github.com/swiftwasm/swift/actions/runs/331791742

[kateinoigakukun]

@MaxDesiatov I tried using a toolchain produced by https://github.com/swiftwasm/swift/runs/1315973687?check_suite_focus=true, but it seems something wrong in SwiftPM change. It doesn't produce a binary with .wasm extension. I confirmed that SwiftPM is built from the latest revision https://github.com/swiftwasm/swift/runs/1315973687?check_suite_focus=true#step:5:731

$ $HOME/Downloads/swift-wasm-5.3-SNAPSHOT-2020-10-27-a/usr/bin/swift package init --name Example --type executable
$ $HOME/Downloads/swift-wasm-5.3-SNAPSHOT-2020-10-27-a/usr/bin/swift build --triple wasm32-unknown-wasi
$ ls .build/debug/
Example                         Example.product                 Example.swiftmodule             ExamplePackageTests.product     description.json
Example.build                   Example.swiftdoc                Example.swiftsourceinfo         ModuleCache                     index

[MaxDesiatov]

Thanks, I'm having a closer look at this now!

[MaxDesiatov]

The .wasm extension issue is fixed in #2125.

Another thing I noticed is that in latest snapshots Foundation can't be linked if you don't pass -Xswiftc -static-stdlib, which seems weird because I didn't expect these to be related:

$ ~/.carton/sdk/wasm-5.3-SNAPSHOT-2020-10-29-a/usr/bin/swift package init --name Example --type executable
$ echo 'import Foundation; print(Date())' > Sources/Example/main.swift
$ ~/.carton/sdk/wasm-5.3-SNAPSHOT-2020-10-29-a/usr/bin/swift build --triple wasm32-unknown-wasi
Sources/Example/main.swift:1:8: error: no such module 'Foundation'
$ ~/.carton/sdk/wasm-5.3-SNAPSHOT-2020-10-29-a/usr/bin/swift build --triple wasm32-unknown-wasi -Xswiftc -static-stdlib
[4/4] Linking Example

[MaxDesiatov]

I've cherry-picked swiftlang/swift-package-manager#3013 to the 5.3 branch and triggered a new build. After that completes, I think that's the best candidate so far 🙂

[kateinoigakukun]

What do you think about tagging swift-wasm-5.3-SNAPSHOT-2020-11-02-a as release-5.3 ? Did you find any serious problem?

[MaxDesiatov]

I didn't, looking good so far. 👍 The tag would be swift-wasm-5.3.0-RELEASE or swift-wasm-5.3-RELEASE, right? Upstream has swift-5.3-RELEASE, without the patch version, which strictly speaking is not compatible with semver that for example SwiftPM uses when resolving packages 🤔

Maybe we should tag both swift-wasm-5.3.0-RELEASE and swift-wasm-5.3-RELEASE to stay on the safe side?

[kateinoigakukun]

Maybe we should tag both swift-wasm-5.3.0-RELEASE and swift-wasm-5.3-RELEASE to stay on the safe side?

I agree with the safe side. 👍

[kateinoigakukun]

I'm going to distribute with the following parameters. If it's ok, please add 👍 reaction on this post

[MaxDesiatov]

Amazing, appreciate it! 👏

[kateinoigakukun]

Distribution started https://github.com/swiftwasm/swift/runs/1363433263?check_suite_focus=true

[MaxDesiatov]

When it finishes, let's use it over the weekend to make sure everything's tagged correctly and works well, last minute checks basically. Then we could announce it widely in the beginning of next week, WDYT? As in, I'm a bit hesitant to announce it widely on Friday 😄

[MaxDesiatov]

As in, we still tag it today, and people who watch the repo will notice it, so no need to hide it from them. If those few people use it today or during the weekend and report issues, that would be useful. But I'm inclined to share it on SwiftWasm Twitter on Monday, in the beginning of the work week. Kind of a slow catious launch 🙂

[kateinoigakukun]

That's a reasonable plan! I'll also spend some time verifying the toolchain this weekend.

[SDGGiesbrecht]

🎉 Working great so far.

The only minor surprise was this (using the Ubuntu 20 toolchain):

error: missing required module 'CFXMLInterface'
  import FoundationXML
         ^

That import is guarded by #if canImport(FoundationXML), and used to be skipped safely. So it seems FoundationXML is half there and half missing. (Adding && !os(WASI) worked just fine.)

[MaxDesiatov]

@SDGGiesbrecht This is very useful, thanks for reporting this!

[kateinoigakukun]

@MaxDesiatov Now the issue was fixed and CI passed. Should we increment patch version for 5.3 release or note it as known issue on release note?

[MaxDesiatov]

One option could be to retag 5.3.0, but I'm not sure if the issue is critical enough. I imagine people would prefer to use the JS API for XML parsing anyway, instead or bundling whole FoundationXML in their apps. We could wait for upstream 5.3.1 and release this FoundationXML removal as a part of SwiftWasm 5.3.1 after that. @SDGGiesbrecht WDYT?

[SDGGiesbrecht]

I don’t think it is worth trying to fix in this release. It is not like there was a preceding release where #if canImport(FoundationXML) worked. FoundationXML isn’t very popular anyway since it is only sort of cross‐platform (it will never be available on iOS).

[MaxDesiatov]

Now that 5.3.0 is released, I'm closing this as resolved.