https://issues.apache.org/jira/browse/ARROW-10838

FWIW, I do not think we should merge this if there are no plans to merge #7767.

I think we should merge this given that we don't know when the PR with tests will be ready.

I don't fully understand what this check is doing

I see it did something which claims to have run cargo build --target wasm32-unknown-unknown:

But it takes a suspiciously short amount of time (8s) and when I do (seemingly) the same thing locally I get a bunch of compilation errors

 Compiling encode_unicode v0.3.6
error[E0433]: failed to resolve: could not find `unix` in `os`
  --> /Users/alamb/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-1.0.5/src/lin.rs:41:18
   |
41 |     use std::os::unix::ffi::OsStringExt;
   |                  ^^^^ could not find `unix` in `os`

error[E0432]: unresolved import `unix`
 --> /Users/alamb/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-1.0.5/src/lin.rs:6:5
  |
6 | use unix;
  |     ^^^^ no `unix` in the root

   Compiling hex v0.4.2
   Compiling tower-service v0.3.0
   Compiling alloc-no-stdlib v2.0.1
   Compiling adler32 v1.0.4
error[E0599]: no function or associated item named `from_vec` found for struct `OsString` in the current scope
  --> /Users/alamb/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-1.0.5/src/lin.rs:48:34
   |
48 |     Some(PathBuf::from(OsString::from_vec(out)))
   |                                  ^^^^^^^^ function or associated item not found in `OsString`
   |
   = help: items from traits can only be used if the trait is in scope
   = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
           `use std::sys_common::os_str_bytes::OsStringExt;`

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0432, E0433, E0599.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `dirs`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

I probably don't have something installed right

Are you building from within the arrow directory, or using -p arrow?

The purpose of adding just the cargo build (or even cargo check) to CI is to prevent making changes (normally feature-gates in SIMD) that break wasm32-unknown-unknown targets.

We have partial wasm32 support in arrow, in the sense that the crate can be built, but not all tests pass, and it's likely that std::fs-related code + some other stuff don't work.
So we'd want to at least test that we don't break support, see ARROW-9088.

I've just tested compiling with the wasm32 target in both Windows and Linux via WSL, and the arrow crate builds. I'm assuming that the 8 seconds taken is due to the build artefacts being cached from some previous build, but @jorgecarleitao would be authoritative in answering that.

If you currently try to run tests without the magic sauce that's in #7767, you get:

$ cargo test --target wasm32-unknown-unknown -p arrow

arrow/rust/target/wasm32-unknown-unknown/debug/deps/arrow-2495d35fed1d3bb9.wasm: 1: Syntax error: end of file unexpected
error: test failed, to rerun pass '--lib'

@nevi-me -- thank you. You are right -- I was not building with -p arrow (so presumably the build errors were from some other crate).

In that case, I agree that this would be a good PR to merge to make sure people don't accidentally introduce new code in arrow that breaks the wasm build .

What do you think @jorgecarleitao ?

I agree with @nevi-me , that this is useful to avoid regressions in being able to compile wasm32. Let's merge this then.