Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can --workspace be removed from cargo check? #10717

Closed
vbn opened this issue Nov 8, 2021 · 3 comments
Closed

Can --workspace be removed from cargo check? #10717

vbn opened this issue Nov 8, 2021 · 3 comments
Labels
A-config configuration C-feature Category: feature request S-actionable Someone could pick this issue up and work on it right now

Comments

@vbn
Copy link

vbn commented Nov 8, 2021

When running build scripts in the workspace, --workspace flag is used unconditionally. Even with rust-analyzer.cargo.noDefaultFeatures=true specified, this flag causes crates marked optional = true to be compiled (the feature for the crate is not turned on).

cargo help check says this:

       --workspace
           Check all members in the workspace.

Currently, the only workaround is to specify the following:

  "rust-analyzer.cargo.runBuildScripts": false,
  "rust-analyzer.procMacro.enable": false

However, this is a hack and a really big hammer which stops all uses of build scripts in the workspace. If --workspace flag is removed, the optional dependencies are ignored (for unspecified features) as expected.

I believe this behavior is problematic especially if rust-analyzer.cargo.noDefaultFeatures is set to true. rust-analyzer.cargo.noDefaultFeatures=true would be a good hint that the user doesn't want to compile everything in the workspace, but only some of the features.

Use case

In our internal project, a project has windows and linux specific dependencies. Some crates are linux only, they have build scripts which only work on linux. They are specified in Cargo.toml behind feature configuration. As long as the relevant feature is not turned on, those crates are not compiled. The dependencies are path specific and marked optional = true. Using rust-analyzer on this workspace will call cargo check --workspace which runs build scripts for dependencies including optional ones. This makes rust-analyzer status always broken.

@Caellian
Copy link

Caellian commented Nov 18, 2021

Found this because of servo/pathfinder requiring objc for metal backend and corresponding example which won't compile on anything other than MacOS (even after installing ObjectiveC) due to build.rs script in objc_exception.

If I'm not mistaken, noted workaround would also disable macro resolution which would make rust-analyzer almost useless for wasm projects relying on macro generated web-sys.

I don't think the feature setting should affect which workspace members are built. Instead, by default, if default-members is present --workspace flag shouldn't be appended and there should be options to:

  • ignore default-members flag and build all workspace members
  • explicitly list which workspace members should be built

Another way of handling this would be to manually --exclude names of all non default-members.

@Veykril Veykril added A-config configuration C-feature Category: feature request S-actionable Someone could pick this issue up and work on it right now labels Dec 14, 2021
@vbn
Copy link
Author

vbn commented Apr 20, 2022

So thanks to #11956, there's a good enough workaround. I can customize the build command to remove --workspace option:

  "rust-analyzer.cargo.runBuildScriptsCommand": [
    "cargo",
    "check",
    "--quiet",
    "--message-format=json"
  ],

I think we should still keep this issue open to verify if we can remove it by default. But my workflow is unblocked now.

@zjp-CN
Copy link

zjp-CN commented Apr 23, 2024

I think this issue can be closed, because setting check.workspace to false has been supported since #16510 .

@Veykril Veykril closed this as completed Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-config configuration C-feature Category: feature request S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

4 participants