automatic download of wasm-opt and wasm-bindgen assumes x86_64

[jbg]

Our CI runs on arm64. Since trunk v0.12 our builds fail with:

error from HTML pipeline

Caused by:
    0: failed to spawn assets finalization
    1: error spawning wasm-opt call
    2: Exec format error (os error 8)

Digging into the automatic download code it looks like it assumes x86_64, which is reasonable considering that neither wasm-bindgen nor binaryen provide binaries for other architectures than x86_64.

Considering there's already some code to check which OS is in use, it might make sense to also check the architecture and provide a less obscure error message if it isn't x86_64 (or maybe just skip wasm-opt in this case?).

In our case the workaround is just to install wasm-opt 101 (we already have it in the CI image, but it's an older version), but I'll also file issues to see if binaryen (and wasm-bindgen) can provide arm64 binaries.

[thedodd]

Reviewing the docs for std::io::Error/ErrorKind we may have to get fancy in order to determine when to provide the more detailed error message. ErrorKind::Other is quite likely the error variant we would get back, so we would have to resort to some form of string matching (which is often a bad idea).

More investigation is needed on best way to handle this.

[jbg]

One approach could be to substitute the actual arch in place of x86_64 in the URLs, and then error out with something like "no suitable wasm-opt (/wasm-bindgen) binary available" when you get a 404 trying to download it. That also has the advantage that new architectures supported by wasm-opt/wasm-bindgen in future get automatically supported by trunk.

It could be reasonable to warn and continue when it's wasm-opt (as opposed to wasm-bindgen) that can't be fetched.

[jbg]

In this case it would make sense to special-case macOS/arm64 though — otherwise M1 users will start to try to fetch the arm64 binaries (which don't exist yet) when x86_64 would work fine thanks to Rosetta 2.

[thedodd]

@jbg yea, interpolating the actual arch into the URL seems like a pretty solid path forward. Right now, it would only clarify the issue, but not actually give the needed binaries, as they do not exist (as mentioned above). Either way, still an improvement.