crates.io release?

[cfallin]

Greetings, friendly VeriWasm folks!

I noticed recently that you had integrated changes from my fork in #2 (thanks!). In addition to that, our efforts to use VeriWasm by default in Lucet (bytecodealliance/lucet#658) will need a way to refer to VeriWasm. The PR currently pulls in a git submodule, and in theory we could point that to this repo. However, it would be preferable if we could pull in VeriWasm as a crate from crates.io, along with other dependencies.

With that background, would you be willing to consider releasing on crates.io? I suspect this wouldn't need to impose much in terms of requirements or process -- with a version like "0.0.1" there are no API stability guarantees, etc., between releases -- but it would be nice to have a release checkpoint, and would make downstream use easier.

Thanks!

[cfallin]

Ah, and as one further thing, I believe doing this would require a new release of yaxpeax-core, since the VeriWasm crate currently depends on a git branch. @iximeow thoughts on this?

[iximeow]

if the VeriWasm folks are down for a cratesio release, i'd be happy to as well! there's a bit of yaxpeax-core that i'd frankly be embarrassed to commit for eternity in a crate but it should be fairly easy to clean up. mostly confusing or downright misleading panic messages on more experimental code paths that VeriWasm doesn't reach. but being a proper crate i'd like to be sensitive to someone else trying to use it in an interesting way too :D

[deian]

+1 totally down!

[enjhnsn2]

Ya, that sounds good to me. Let me know when the vw-tweaks yaxpeax-core branch is in a crate, and I'll publish VeriWasm as well.

[iximeow]

on the yaxpeax-core side: last minute cleanup done and crate version 0.0.1-vw-tweaks is published! i noticed several println that i suspect VeriWasm would hit in practice, and made them tracing::trace! invocations instead. VeriWasm looks to build from the published crate but i don't have good objects on hand to make sure that things actually work.

the important logging adjustments are in process.rs and control_flow/mod.rs but none of this should be a functional change aside from the opt-in-able logging.

[enjhnsn2]

@cfallin I have published the crate: https://crates.io/crates/veriwasm . Right now it is basically the exact state as after I merged your changes (the only difference is that it checks that the usage of RBP is safe, but that should be irrelevant to the exposed library interface). I will publish crates at least a few more times this summer, as there has been lots of refactoring going on + wasmtime & arm support on its way. At some point (likely after the wasmtime support is in a passable state), I'll work on a better library interface for compilers to use besides the somewhat impromptu one we have now.

[cfallin]

Fantastic, thank you @enjhnsn2!

[iximeow]

👋 there's a compilation issue when building yaxpeax-core in a crate tree that includes the tracing/log feature, i've fixed that in 0.0.2-vw-tweaks. this ends up being a conflict with Wasmtime, and seems to be the main remaining issue with landing VeriWasm support in Lucet. @enjhnsn2 could you bump the yaxpeax-core version to 0.0.2-vw-tweaks and publish a VeriWasm 0.1.1, please?

[enjhnsn2]

will do that now

[enjhnsn2]

@cfallin @iximeow I pushed the new version of the VeriWasm crate that uses the 0.0.2-vw-tweaks branch of yaxpeax-core. Let me know if you run into any other problems.