//tools/rust_analyzer:gen_rust_project does not build all required targets

[martingms]

When using bazel's --disk_cache (and possibly in other remote cache situations?) gen_rust_project can generate rust-project.json files that contains paths in "proc_macro_dylib_path" that are invalid at the time of generation.

One easy to reproduce example as long as cargo crates with proc-macros are used in the project: Enable --disk_cache, run a full build to populate the cache, bazel clean, run a new full build for good measure, run //tools/rust_analyzer:gen_rust_project.
"proc_macro_dylib_path" for e.g. clap_derive will now be something like. /home/<...>/execroot/_main/bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_rust++crate+crates__clap_derive-4.5.18/libclap_derive-2275298359.so which has not been rebuilt and therefore does not exist.

I've not found a way to force it to be built manually either in this case, where I depend on the clap_derive crate transitively, so it's not available at @crates//:clap_derive or similar.

[martingms]

Took a quick look. gen_rust_project shells out to bazel build <... aspect stuff ...> @//... by default, but takes targets as an argument. This makes it possible to generate all crates at least by running ... gen_rust_project -- @//... @crates//... instead, but that still doesn't help w.r.t. transitive deps that are not visible of course...

[ajwerner]

My workaround for this has been to separately in vscode as a startup task to build everything. It's not beautiful.

[martingms]

My workaround for this has been to separately in vscode as a startup task to build everything. It's not beautiful.

I don't mind ugly as long as it works.. How do you build the transitive deps though?