Stream: git-wasmtime

Topic: wasmtime / PR #12706 Fix build without `wat` feature.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 07:33):

PiotrSikora opened PR #12706 from PiotrSikora:wat to bytecodealliance:main.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 07:33):

PiotrSikora requested dicej for a review on PR #12706.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 07:33):

PiotrSikora requested wasmtime-core-reviewers for a review on PR #12706.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 08:58):

github-actions[bot] added the label wasmtime:api on PR #12706.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 08:58):

github-actions[bot] added the label wasmtime:c-api on PR #12706.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 14:09):

dicej submitted PR review:

Thanks! I take it CI didn't cover this case, correct? Would you mind adding a line to e.g. here which covers the scenario to ensure this doesn't regress in the future?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 17:04):

PiotrSikora commented on PR #12706:

Thanks! I take it CI didn't cover this case, correct?

Correct.

Would you mind adding a line to e.g. here which covers the scenario to ensure this doesn't regress in the future?

There are actually 2 separate cases here (bundled into single PR per contributing guidelines against trivial changes), that I've run into within a few days from each other, and neither would be covered by those tests.

  1. The C++ API issue requires linking C++ code against Wasmtime built without wat feature enabled (i.e. running test_capi job with cmake -S examples -B examples/build [...] -DWASMTIME_FEATURE_WAT=OFF and then building the examples). I don't mind adding this, but it seems quite costly in terms of the CPU time, and it would target only this single feature, so in practice we'd need to add the whole matrix if we want to be exhaustive.

  2. The unused variable case could be detected with cargo check build with default-features = false, features = ["cranelift", "compile-time-builtins"], but detecting issues like that would require building with all possible combinations, unless we want to target this very specific case.

Let me know how to proceed. Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Mar 03 2026 at 22:33):

dicej commented on PR #12706:

Let me know how to proceed. Thanks!

Thanks for the explanation. Let's add the additional cargo check but not the cmake job; I agree that the extra CPU time of the cmake one is not worth it.

Last updated: Mar 23 2026 at 16:19 UTC