Wrong features resolution in Visual Studio Code

Hi there,

When I have a shared library with a feature that either exports one or another method, Visual Studio Code with the Rust plugin or rust-analyzer plugin doesn't correctly catch what is currently exposed:

  • library shared: exports one if feature one is enabled, else exports two
  • binary first imports shared with feature one, uses one
  • binary second imports shared with no features, uses two

If I run cargo run in first or second, the compilation succeeds and I get the result I expect. However, Visual Studio Code complains in second that it doesn't know the method two.

I created a little test repo here:

https://github.com/ineiti/test_vsc

Is this a bug, or a misunderstanding on my side?

Thanks,

Ineiti

Features should be additive. Because in a dependency tree, if one crate requires feature "foo" of crate A cargo will compile that crate only once with that feature turned on. If another crate is dependant on crate A but without that feature, it will reuse the already compiled crate.

In your case, cargo compiles your crate only once with the total of features it found in the dependency tree.

If you run cargo check (or cargo run --bin second) in the workspace root you get the same error that you see in vscode. When looking at second individually, everything seems fine, but in the context of the workspace, first enables a feature that breaks second, as explained by erelde.

But it works if I use cargo run in either first or second...

Yes, cargo check in the root directory doesn't work, it gives me an error.

In my 'real' example, I need to add Send + Sync to a trait, but only for the binary, not for the wasm-part, because it doesn't support it. Does that mean that I cannot have this in the same workspace? Or that I need to think of another way to combine this?

Another one of these "just when it all made sense" moments...

Recommendation: Use Send + Sync unconditionally. If you need a value that isn't Send under wasm (or any single-threaded environment), the send_wrapper crate can handle that for you by enforcing at run time that it isn't used from other threads.

Note that you can still use std::sync::Arc and such in wasm; no special measures are needed for the basics.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.