Integration with rust-analyzer is broken for bindings

[peterhuene]

Repro steps

1. cargo component new repro
2. cd repro
3. Run VS Code with rust-analyzer enabled and open src/main.rs.

rust-analyzer should trigger a check command that will generate a target/bindings/repro/target.wasm file containing the current target world for the project; the target is empty for command projects by default, so the generated bindings mod will be empty.

4. Create a wit directory.
5. Add a test.wit file with the following contents:

package repro:test

world repro {
    import test: func()
}

6. In VS Code, manually save src/main.rs to trigger a reparse.
7. In the main function in src/main.rs, type bindings::.

Expected results

rust-analyzer should offer autocomplete suggestions for the imported function.

Actual results

Nothing happens.

Remarks

Right now, the cargo_component_bindings::generate! macro reads the target wasm file (which is very small and only contains type information) to generate bindings and emits a include_bytes! with the hopes that a dependency on the file will trigger a rebuild if it changes.

However, it appears that rust-analyzer doesn't respect changes to the file to reparse; it continues to use a cached evaluation of the proc-macro.

This may be related to rust-lang/rust-analyzer#13668, but I can't say for sure.

Workarounds

Restarting the rust-analyzer server after modifying the WIT files forces the re-evaluation of the macro with the latest bindings information.

[peterhuene]

This has likely been present since the switch over from pre-generating the bindings into a separate crate to using a proc-macro to do so.

[peterhuene]

Based on my limited understanding of rust-analyzer, it looks like it caches the expansion of the macro unless tokens change inside the macro invocation site?

So another workaround is to change cargo_component_build::generate!(); to cargo_component_build::generate!({});; the addition of the { and } tokens will cause a re-expansion of the macro and thus get the updated bindings.

[peterhuene]

After diving into the rust-analyzer code briefly, I would say this is unrelated to the above linked rust-analyzer issue; it's a separate issue where the recursively expanded proc-macro depends on a file via include_bytes!, changes to the file would ideally be treated as changes to the syntax tree at the macro invocation site to re-expand the macro.

[sehz]

any update? this make it harder to develop on VSCode

[peterhuene]

Hi @sehz, unfortunately not yet as I haven't had a chance to really get into rust-analyzer's source to investigate a proper solution to this.

It might be as "simple" as having rust-analyzer configuration to have additional watch entries that causes a complete reparse on the component crate (not unlike editing Cargo.toml).

I don't think there's anything we can do in cargo-component to fix this, unfortunately.

[peterhuene]

Based on a suggestion from Alex, I'm going to be altering how we generate bindings to be similar to how we use to do it.

It'll be a breaking change for anyone that is currently passing arguments to the macro as they have to move into Cargo.toml, but with these changes, rust-analyzer will correctly pick up changes to the wit on the next parse.

[peterhuene]

This should be fixed in release 0.4.0.

[tomasol]

I have the same problem with cargo-component-bindings 0.4.1 and rust-analyzer 1.73.0 except not even restarting RA works. Also, the generated code does not show in cargo doc, the only way to see it is using cargo expand.

Observation

Issuing Expand macro recursively on the line cargo_component_bindings::generate!() results in:

// Recursive expansion of generate! macro
// =======================================

#[doc = r" Generated bindings module for this component."]
#[allow(dead_code)]
pub(crate) mod bindings {}

[peterhuene]

Hi @tomasol: what version of cargo-component are you using and do you have a repro project I could take a look at?

Are you using VSCode or Emacs?

[tomasol]

@peterhuene I am using cargo-component 0.4.1, created repo tomasol/cargo-component-issue139 , am using VSCode.
When using wit-bindgen, I have the auto-completion working correctly, Expand macro recursively works as expected on the line wit_bindgen::generate! .

One strange thing happened during my testing of the cargo_component module - after not doing any changes to the code, I was able to navigate to bindings.rs from the imported function, Expand macro recursively was working. After I restarted RA, it stopped working again. I did not experience such issues with wit-bindgen.

Regarding cargo doc, the wit_bindgen module shows both the trait and the imported function, whereas cargo_component does not show anything; this is a a separate issue probably caused by using pub(crate) modifier in generated mod bindings.