How to debug `bindgen!`? · wasmtime

I tried running rustc --profile=check -- -Zunpretty=expanded to see the result of the expansion of the macro and I see the code contains const str with the correct updated WIT files, but the generated types are stale and don't get updated... If I use include_generated_code_from_file, I end up with a file in the target directory without any bindings just some code related the the Linker.

Alternatively, the macro system is pretty obscure to me and I was wondering if there was a cli around there to do good old Just Work :tm: code generation for host bindings with wasmtime?

Alex Crichton (Dec 11 2024 at 21:28):

Have you tried WASMTIME_DEBUG_BINDGEN=1 from the debug section of the docs? Is the issue that a recompile isn't happening on WIT file changes or that the changes aren't resulting in what you'd expect?

Currently there's no CLI integration for bindings generation, it's only through the procedural macro

raskyld (Dec 11 2024 at 21:30):

// This is an in-source alternative to using `WASMTIME_DEBUG_BINDGEN`.
    //
    // Note that if this option is specified then the compiler will always
    // recompile your bindings. Cargo records the start time of when rustc
    // is spawned by this will write a file during compilation. To Cargo
    // that looks like a file was modified after `rustc` was spawned,
    // so Cargo will always think your project is "dirty" and thus always
    // recompile it. Recompiling will then overwrite the file again,
    // starting the cycle anew. This is only recommended for debugging.
    //
    // This option defaults to false.
    include_generated_code_from_file: false,

raskyld (Dec 11 2024 at 21:31):

Basically, the only way I can really see the final types is through autocompletion with rust analyzer, or using the expansion with rustc but I don't see changes reflected

raskyld (Dec 11 2024 at 21:37):

 #[component(variant)]
pub enum Stability {

    #[component(name = "stable")]
    Stable((Version, Option<Version>)),

    #[component(name = "unstable")]
    Unstable((Version, Option<Version>)),

    #[component(name = "unknown")]
    Unknown,
 }

variant stability {
        stable(tuple<version, option<version>>),
        unstable(tuple<version, option<version>>),
        unknown,
    }

    variant stability {
        stable(u8),
        unstable(u8),
        unknown,
    }

I see the updated WIT content in the const _: &str of the expanded code but the type is still the old one

raskyld (Dec 11 2024 at 21:47):

I just realised what is the problem, I have a crate with different host bindings split in different modules, each target a different world. And I just noticed the expanded code contains the content of ALL WIT packages, not just the one of the current module I was working with. And one of this package have a dependency on the module I was working and had the "old" version in its deps folder :man_facepalming:

raskyld (Dec 11 2024 at 21:54):

I think I just misused the macro, I tried to split the different package in different rust modules but that doesn't make sense since the macro already create sub-modules matching the package name and the interfaces names.. right?

Victor Adossi (Dec 12 2024 at 07:06):

Hey just making sure, but you're using cargo expand right along with the other tooling right? Luckily Alex already recommended the stuff for printing out the output, but cargo expand is really useful for quick spot checks/fast iteration

raskyld (Dec 12 2024 at 08:34):

cargo expand is a wrapper around rustc --profile=check -- -Zunpretty=expanded If I am correct :D

Ramon Klass (Dec 12 2024 at 11:31):

I usually place the macro call in lib.rs but what I've seen more than once is people doing pub mod bindings { bindgen!(...); }; to have a namespace where only the generated code lives

Stream: wasmtime

Topic: How to debug `bindgen!`?

raskyld (Dec 11 2024 at 20:40):