grep: allow wasm32-wasip1 cargo check

[wondr-wclabs]

Fixes #20.

onig_sys builds bundled C sources, so cargo check --target wasm32-wasip1 currently fails unless the caller also provides a C WASI sysroot. That makes the Rust target check depend on external C toolchain setup before the uu_grep crate itself is checked.

This PR target-gates the Oniguruma dependencies away from WASI builds and adds a small WASI matcher fallback for ASCII literal patterns. I kept the fallback intentionally narrow: non-WASI builds keep the existing Oniguruma behavior, while WASI builds return an explicit error for regex features that would require Oniguruma. Pulling in a different pure-Rust regex engine for WASI would make the command compile, but it would also create a second regex semantics path for BRE/ERE/PCRE behavior, which seems worse than failing clearly for unsupported cases.

I also added a CI job that runs the issue reproducer command directly: cargo check --target wasm32-wasip1.

Checked locally: cargo fmt --all -- --check, cargo check, cargo test, cargo clippy --all-targets --workspace -puu_grep -- -D warnings, cargo check --target wasm32-wasip1, and cargo clippy --target wasm32-wasip1 --workspace -puu_grep -- -D warnings. I also tried cargo test --target wasm32-wasip1 --no-run; that currently stops in the dev-dependency stack because socket2 does not support the target, so I left this PR scoped to the reported cargo check failure.

[codspeed-hq]

Merging this PR will not alter performance

✅ 10 untouched benchmarks
⏩ 17 skipped benchmarks¹

---

_{Comparing wondr-wclabs:codex/wasm32-wasip1-check (740b302) with main (d28bf76)}

Footnotes

1. 17 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[oech3]

Can we build oniguruma for wasip1? or remove oniguruma from all platforms for simplicity?

[sylvestre]

Thanks for tackling this! I'd rather not drop Oniguruma on WASI - it forks the matcher and loses -i, BRE/ERE/PCRE, etc.

We don't need to: the uutils playground already builds grep for wasm32-wasip1 with full Oniguruma by providing a WASI sysroot. So to @oech3's question - yes, we can build oniguruma for wasip1, and we already do in production.

Could you redo it that way? Drop the Cargo.toml gating and the second CompiledPattern/is_word_match, keep the single Oniguruma path, and have the CI job set up a WASI SDK sysroot before cargo check, like uutils.github.io's website.yml:

WASI_SDK_DIR="wasi-sdk-25.0-x86_64-linux"
curl -sL "https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk-25/${WASI_SDK_DIR}.tar.gz" | tar xz
export WASI_SDK_PATH="$PWD/${WASI_SDK_DIR}"
export CC_wasm32_wasip1="$WASI_SDK_PATH/bin/clang"
export CFLAGS_wasm32_wasip1="--sysroot=$WASI_SDK_PATH/share/wasi-sysroot"
cargo check --target wasm32-wasip1

That keeps one matcher, real regex on WASI, and a green check. Thanks!

[oech3]

Can we enable expr.wasm on uutils/coreutils by same way?

[sylvestre]

probably, yes
do you want to give it a try ?

[oech3]

Yes

[oech3]

https://github.com/oech3/coreutils/actions/runs/28317862344/job/83894676386#step:18:259

[DePasqualeOrg]

I'm maintaining my own patched fork of grep to compile for WebAssembly. Claude Fable 5 noticed something that could be improved in this PR, which would make my patch unnecessary. I'm not claiming this as my own analysis, just passing it on in case it's helpful:

oniguruma compiles and passes full BRE/ERE/-P testing on wasm32-wasip2 when CC_wasm32_wasip2/CFLAGS_wasm32_wasip2 point at a wasi-sdk sysroot, so it may be worth making the literal-only fallback a cargo feature rather than a hard target_os = "wasi" gate. That way WASI builds that do have a C sysroot keep the real regex engine.