Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple packages with deps that have the same versions #1996

Open
jsturtevant opened this issue Feb 4, 2025 · 7 comments · Fixed by #2071
Open

Support multiple packages with deps that have the same versions #1996

jsturtevant opened this issue Feb 4, 2025 · 7 comments · Fixed by #2071

Comments

@jsturtevant
Copy link
Contributor

I mis-configured wit-bingen macro and got the error message:

proc macro panicked
message: assertion failed: prev.is_none()

When trying to debug it I tried using cargo expand and cargo docs to track down what I did wrong but the gave the same error.

After some digging and forking the various repositories, I eventually tracked the error message to this repo which has a bunch of asserts: https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-tools%20%20prev.is_none&type=code

As a developer it would be nice to have a better error message for these asserts to improve the debugging experience.

@alexcrichton
Copy link
Member

In theory asserts should never happen and they're only intended for developers of the tool itself, any other error should be signaled through a Result or some sort of other first-class mechanism. In that sense I think the "true bug" here lies in whatever configuration you fed to wit-bindgen and it panicked. The macro itself should never panic ideally.

Although naturally internal assertions do trip (e.g. this) and I don't disagree that having better error messages would be helpful. That being said though I wouldn't want to improve things to expect all users to see them because the true bug is having this trip at all.

@jsturtevant
Copy link
Contributor Author

The mis-configuration came from using the macro in a way that was intended for testing purposes only (https://docs.rs/wit-bindgen/latest/wit_bindgen/macro.generate.html#options-to-generate)

// Usually used in testing, our test suite may want to generate code
// from wit files located in multiple paths within a single mod, and we
// don't want to copy these files again.

The configuration was bringing in two references to the wasi-io:

wit_bindgen::generate!({
    inline: "
        package wasmtime:test;

        world test {
            include wasi:cli/[email protected];
            include wasi:http/[email protected];
            include wasi:config/[email protected];
            include wasi:keyvalue/[email protected];
            include wasi:tls/[email protected];  #added line
        }
    ",
    path: [
        "../wasi-http/wit", // this also has a deps folder to io
        "../wasi-config/wit",
        "../wasi-keyvalue/wit",
        "../wasi-tls/wit/",  // this has a deps folder to io
    ],
    world: "wasmtime:test/test",
    features: ["cli-exit-with-code", "tls"],
    generate_all,
});

The two wasi-io deps collided with the error "prev.is_none()`. Technically I guess this is an error and not an assert?

@alexcrichton
Copy link
Member

Oh dear that looks like something that should be expected to work. That documentation is a bit outdated and the array-of-paths situation is a bit more expected to work nowadays as well.

Would you be able to make a reproduction? If it's still using wit-bindgen that's ok, I can work on reducing it as a reproduction for this repository.

@jsturtevant
Copy link
Contributor Author

I believe this is a simplified reproduction: https://github.com/jsturtevant/wasi-cli/tree/prev-is-none

I am getting:

cargo build 
  Compiling wit-bindgen-rust-macro v0.39.0
   Compiling wit-bindgen v0.39.0
   Compiling path-repo v0.1.0 (/home/jstur/projects/wit/wasi-cli)
error: proc macro panicked
  --> src/main.rs:2:5
   |
2  | /     wit_bindgen::generate!({
3  | |         inline: "
4  | |             package wasmtime:test;
...  |
17 | |         generate_all,
18 | |     });
   | |______^
   |
   = help: message: assertion failed: prev.is_none()

I wasn't able to figure out how to load multiple deps via just the wasm-tools component wit command

alexcrichton added a commit to alexcrichton/wasm-tools that referenced this issue Feb 25, 2025
This commit fixes a runtime assertion tripping to instead being a
first-class error returned by `bail!`. This cannot currently be
triggered from the CLI and is only reachable through API usage of the
`wit_parser::Resolve` type. This usage is reachable through generators
such as `wit_bindgen::generate!`, though.

The error here happens when a package is re-added to a `Resolve` twice.
This currently isn't supported and would require some large refactoring
to support. This should probably be fixed at some point in the future to
actually be supported but until that happens it's best to have a
first-class error for this case instead of an internal assertion
tripping.

Closes bytecodealliance#1996
alexcrichton added a commit to alexcrichton/wasm-tools that referenced this issue Feb 25, 2025
This commit fixes a runtime assertion tripping to instead being a
first-class error returned by `bail!`. This cannot currently be
triggered from the CLI and is only reachable through API usage of the
`wit_parser::Resolve` type. This usage is reachable through generators
such as `wit_bindgen::generate!`, though.

The error here happens when a package is re-added to a `Resolve` twice.
This currently isn't supported and would require some large refactoring
to support. This should probably be fixed at some point in the future to
actually be supported but until that happens it's best to have a
first-class error for this case instead of an internal assertion
tripping.

Closes bytecodealliance#1996
@alexcrichton
Copy link
Member

Ok I got a chance to debug and look into this and the best I could come up with is promoting the assertion to an error. Actually fixing this would require a relatively large refactoring/investment which I don't have time for. I'd also like to eventually support this on the CLI but that'll also take some refactoring and care which isn't trivial.

Definitely file more issues though if other internal assertions crop up!

github-merge-queue bot pushed a commit that referenced this issue Feb 25, 2025
This commit fixes a runtime assertion tripping to instead being a
first-class error returned by `bail!`. This cannot currently be
triggered from the CLI and is only reachable through API usage of the
`wit_parser::Resolve` type. This usage is reachable through generators
such as `wit_bindgen::generate!`, though.

The error here happens when a package is re-added to a `Resolve` twice.
This currently isn't supported and would require some large refactoring
to support. This should probably be fixed at some point in the future to
actually be supported but until that happens it's best to have a
first-class error for this case instead of an internal assertion
tripping.

Closes #1996
@jsturtevant
Copy link
Contributor Author

Should we keep this open? I can rename it to reflect the error.

@alexcrichton
Copy link
Member

Oh sure yeah, sounds good

@alexcrichton alexcrichton reopened this Feb 25, 2025
@jsturtevant jsturtevant changed the title Improve error messages for the asserts in the various tools Support multiple packages with deps that have the same versions Feb 25, 2025
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 a pull request may close this issue.

2 participants