Learn cfgs enabled in build.rs

[fitzgen]

Wasmtime enables cfg(compiler) when one of its compilers (Cranelift or, soon, Winch) is available and therefore JIT compilation is available. This cfg is enabled in build.rs when the cargo features for the underlying compilers are enabled. This is much easier and more future proof than writing out cfg(any(feature = "cranelift", feature = "winch")) all over the place, which is why things are done this way.

However, rust-analyzer does not treat code blocks guarded by #[cfg(compiler)] as enabled, and fails to do autocomplete/jump-to-def/etc within these regions, even though changing the cfg to the wordier cfg(any(...)) does work.

It would be nice if rust-analyzer looked at the cfgs defined by build.rs and enabled them for the project.

[Veykril]

Unsure how we would get to the output there since we have cargo execute the build scripts which will in turn eat that. I guess we could check <CRATE_OUT_DIR>/../output and parse that?

Actually, shouldn't we be doing this already? If I am not mistaken the cfg field of BuildScript is just this right?

[flodiebold]

Actually, shouldn't we be doing this already? If I am not mistaken the cfg field of BuildScript is just this right?

Yeah, that's what I thought as well.

[fitzgen]

FWIW, I can repro in the wasmtime repository in, for example, the code for wasmtime::Func::new at crates/wasmtime/src/func.rs line 354.

[Veykril]

Out of curiosity, do the logs complain about cyclic dependencies? And does r-a also complain about cfg(cranelift) annotated things? (I know that cranelift is a default feature in wasmtime, but it might be that r-a gets confused about that for some other reason which would cause htis problem then).

Will look into this myself tomorrow otherwise

[fitzgen]

Can you point me at a resource for how to get r-a logs?

[Veykril]

I only know how to get to those in VSCode which I believe you aren't using 😅

It's fine though, I'll checkout wasmtime tomorrow or so

[fitzgen]

Yeah, I'm using emacs.

[flodiebold]

On Emacs, there should be a *rust-analyzer::stderr* buffer (though if you're using eglot it might be different).

[fitzgen]

I restarted rust-analyzer and I did get this message in the stderr buffer:

[ERROR project_model::workspace] cyclic deps: wasmtime(CrateId(344)) -> wasi_cap_std_sync(CrateId(323)), alternative path: wasi_cap_std_sync(CrateId(323)) -> wasi_common(CrateId(324)) -> wasmtime(CrateId(344))
[ERROR project_model::workspace] cyclic deps: wasmtime_component_macro(CrateId(380)) -> wasmtime(CrateId(344)), alternative path: wasmtime(CrateId(344)) -> wasmtime_component_macro(CrateId(380))
[ERROR project_model::workspace] cyclic deps: wasmtime_wasi(CrateId(412)) -> wasi_cap_std_sync(CrateId(323)), alternative path: wasi_cap_std_sync(CrateId(323)) -> wasi_common(CrateId(324)) -> wasmtime(CrateId(344)) -> wasmtime_wasi(CrateId(412))
[ERROR project_model::workspace] cyclic deps: wasmtime_wasi(CrateId(412)) -> wasi_common(CrateId(324)), alternative path: wasi_common(CrateId(324)) -> wasmtime(CrateId(344)) -> wasmtime_wasi(CrateId(412))
[ERROR project_model::workspace] cyclic deps: wasmtime_wasi(CrateId(412)) -> wasi_tokio(CrateId(327)), alternative path: wasi_tokio(CrateId(327)) -> wasi_cap_std_sync(CrateId(323)) -> wasi_common(CrateId(324)) -> wasmtime(CrateId(344)) -> wasmtime_wasi(CrateId(412))
[ERROR project_model::workspace] cyclic deps: wasmtime_wasi(CrateId(412)) -> wasmtime(CrateId(344)), alternative path: wasmtime(CrateId(344)) -> wasmtime_wasi(CrateId(412))
[ERROR project_model::workspace] cyclic deps: wiggle(CrateId(425)) -> wasmtime(CrateId(344)), alternative path: wasmtime(CrateId(344)) -> wasmtime_wasi(CrateId(412)) -> wiggle(CrateId(425))
[ERROR project_model::workspace] cyclic deps: wiggle_macro(CrateId(444)) -> wiggle(CrateId(425)), alternative path: wiggle(CrateId(425)) -> wiggle_macro(CrateId(444))
[ERROR project_model::workspace] cyclic deps: wiggle_test(CrateId(445)) -> wiggle(CrateId(425)), alternative path: wiggle(CrateId(425)) -> wiggle_test(CrateId(445))

[Veykril]

Then this could likely be caused by us not handling cyclic deps yet, that is known to cause some issues at least #14167

[1024bees]

We're seeing a similar issue described at esp-rs/esp-template#58. We have a cfg enabled in build.rs, like wasmtime, and details of what we're seeing are detailed in the linked issue

I am not seeing the cyclic deps error message that wasmtime seems to be emitting.

Not trying to conflate these problems -- I can create another issue if maintainers think it is pragmatic. Also I can spend some time debugging this if I could get useful state I can dump. Very open to hack on RA to diagnose this, given some direction!

[svix-jplatte]

Seeing the same issue without cyclic dependencies, possibly relevant that the package in question contains both lib.rs and main.rs? Or any other info needed?