Skip to content

Conversation

jeffcharles
Copy link
Collaborator

@jeffcharles jeffcharles commented Jul 15, 2025

Description of the change

This implements #962 to have plugins target WASI preview 2. This would represent a breaking change for the Javy plugin API in the following ways:

  • plugins now need to be compiled to WASI preview 2 instead of WASI preview 1 and export particular functions with particular types in their WIT definitions
  • compile_src: func(bytecode_ptr: u32, bytecode_len: u32) -> () becomes compile-src: func(bytecode: list<u8>) -> result<list<u8>, string>
  • initialize_runtime: func() -> () becomes initialize-runtime: func() -> ()
  • invoke: func(bytecode_ptr: u32, bytecode_len: u32, fn_name_ptr: u32, fn_name_len: u32) -> () becomes invoke: func(bytecode: list<u8>, function: option<string>);
  • canonical_abi_realloc(old_ptr: u32, old_size: u32, alignment: u32, new_size: u32) becomes cabi_realloc(old_ptr: u32, old_size: u32, alignment: u32, new_size: u32)

Why am I making this change?

WASI preview 1 will be deprecated at some point in the future. We should use WASI preview 2 to ensure we can continue to compile Javy.

Checklist

  • I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli and javy-plugin do not require updating CHANGELOG files.
  • I've updated the relevant crate versions if necessary. Versioning policy for library crates
  • I've updated documentation including crate documentation if necessary.

@jeffcharles jeffcharles marked this pull request as ready for review August 25, 2025 17:01
@jeffcharles jeffcharles changed the title Proposal for WASI p2 adoption Implement WASI preview 2 plugin RFC Aug 25, 2025
Copy link
Member

@saulecabrera saulecabrera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good to me. Left a first round of comments. Since the diff is a bit large, I'll give it another pass just to make sure I didn't miss anything.


fn validate(plugin_bytes: &'a [u8]) -> Result<()> {
let plugin_bytes = match javy_plugin_processing::extract_core_module(plugin_bytes) {
Err(e) => bail!("Problem with plugin: {e}"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit:

Suggested change
Err(e) => bail!("Problem with plugin: {e}"),
Err(e) => bail!("Could not process plugin: {e}"),

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe "Could not validate plugin" ?

@@ -81,12 +97,16 @@ impl Plugin {

let module = walrus::Module::from_buffer(plugin_bytes)?;

if let Err(err) = validate_exported_func(&module, "initialize_runtime", &[], &[]) {
if module.exports.get_func("compile_src").is_ok() {
bail!("Problem with plugin: Using unsupported legacy plugin API");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar here? Failed to validate? Or something along those lines?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given how the functionality in this module has grown in complexity, I think it'd really useful to introduce snapshot testing for the generated code, mainly to make it easier for reviewers to have an better idea of how the generated code looks like, when introducing net new code, and also to make it easier to spot any new changes to existing code.

Comment on lines 19 to 26
if !Parser::is_component(component_bytes) {
if !Parser::is_core_wasm(component_bytes) {
bail!("Expected Wasm component, received unknown file type");
} else {
bail!("Expected Wasm component, received Wasm module");
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm finding this a bit hard to read, couldn't we do something like:

if !Parser::is_component(...) && !Parser::is_core_wasm{ bail!(...) }
if !Parser::is_component(...) { bail!(...) }

I think it's mostly the nested if which I find hard to read.

@jeffcharles jeffcharles merged commit 416358a into main Aug 28, 2025
4 checks passed
@jeffcharles jeffcharles deleted the jc.wasi-p2 branch August 28, 2025 20:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants