Skip to content

Build targets of workspace crates do not appear to be honoured #11268

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

Closed
huntc opened this issue Jan 12, 2022 · 2 comments
Closed

Build targets of workspace crates do not appear to be honoured #11268

huntc opened this issue Jan 12, 2022 · 2 comments

Comments

@huntc
Copy link
Contributor

huntc commented Jan 12, 2022

rust-analyzer version: rust-analyzer version: 54782428a 2022-01-12 dev

rustc version: rustc 1.59.0-nightly (c5ecc1570 2021-12-15)

Further to the "Respect .cargo/config.toml" PR, the config.toml file of a crate within a workspace does not appear to be honoured. For example, if I have a project named client and it has two crates, app and embedded-app, and embedded-app has a .cargo/config.toml, then the latter does not appear to be considered when determining build targets.

To reproduce this issue:

  1. Download the branch at Upgrade Embassy version titanclass/embassy-start#4
  2. rustup target add thumbv7em-none-eabihf if you don't have that target
  3. Open the project's workspace file (embassy-start.code-workspace) in VSC
  4. Navigate to client/embedded-app/src/boards/nrf52840_dk.rs
  5. Wait for RA to complete its indexing
  6. Note that interrupt::take! on L18 is able to be resolved
  7. Remove the "rust-analyzer.cargo.target": "thumbv7em-none-eabihf" from the workspace file
  8. Reload RA
  9. Wait for RA to complete its indexing
  10. Note that interrupt::take! can no longer be resolved

My expectation is that the build target of client/.embedded-app/.cargo/config.toml should be honoured, and that I should not have to declare a rust-analyzer.cargo.target.

Related? #8521

@huntc
Copy link
Contributor Author

huntc commented Jan 12, 2022

I made some progress by running my own RA build and printing out the cargo.toml's within that were being used to determine the various targets. My eprintln was in cargo_workspace.rs/cargo_config_build_target. In my example, this is what I get:

config ManifestPath { file: AbsPathBuf("/Users/huntc/Projects/titanclass/embassy-start/client/Cargo.toml") } "cargo" "-Z" "unstable-options" "config" "get" "build.target"
result None
config ManifestPath { file: AbsPathBuf("/Users/huntc/Projects/titanclass/embassy-start/network-protocol/Cargo.toml") } "cargo" "-Z" "unstable-options" "config" "get" "build.target"
result None
config ManifestPath { file: AbsPathBuf("/Users/huntc/Projects/titanclass/embassy-start/server/Cargo.toml") } "cargo" "-Z" "unstable-options" "config" "get" "build.target"
result None

...None meaning that no target is being resolved out of the cargo.toml's that are used.

Perhaps client/embedded-app/Cargo.toml and server/embedded-app/Cargo.toml would be needed to determine the needed build targets here?

@huntc
Copy link
Contributor Author

huntc commented Jan 14, 2022

I've come to the conclusion that RA is working as intended. When it performs a cargo check, it does so at the workspace level if there is one, or if there's not, then just the crate. Cargo workspaces aren't effective when there are multiple targets being used as expressed by config.toml. In fact, config.tomls are only applied when cargo is working within that particular directory.

I have since removed workspaces from situations where there are no common targets between crates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant