Cargo `build-dir` support

[epage]

The Cargo team has done a Call for Testing for the unstable build-dir and I'm looking into stabilizing it. This allows users to move intermediate artifacts out of their target-dir. With how r-a is using target-dir (e.g. #20072), it seems that build-dir will be the more appropriate location moving forward.

Note:

• build-dir files do not have compatibility guarantees
• In the future we may change the default build-dir
• In the future, we may change the layout of build-dir

See rust-lang/cargo#14125 (comment)

[ShoyuVanilla]

I really like the new build-dir feature and rust-analyzer making use of it sounds like a great idea.
I was wondering, though: is there a command to query Cargo for the current workspace's build-dir path?

It seems this path can be configured in various ways—through environment variables, config.toml, and with template substitutions. While we could certainly re-implement the resolution logic in rust-analyzer, even small discrepancies in implementation details might lead to subtle bugs, especially if Cargo changes its behavior in the future. So I think having an official command or API for this would be quite helpful.

[epage]

Like target-dir, build-dir will be readable with cargo metadata --no-deps (the flag being needed to avoid lockfile problems r-a has)

[Veykril]

That won't work for us. We need to know the build-dir before invoking cargo metadata to figure out where to copy the lockfile to before we can invoking cargo metadata with the copy. Running cargo metadata --no-deps to discover the value of build-dir makes it pointless to copy the lockfile in the first place as we do this to avoid the issue of cargo metadata updating the lockfile.

Which is the same reason why our target-dir discovery currently re-implements roughly what cargo does instead of using the cargo metadata target-dir listing.

[lnicola]

Is there a way to make that work (in Cargo) using cargo config get?

[Veykril]

That's what we are doing right now, but that only handles .cargo/config.toml, we also need to honor the other ways this can be set like env vars -> reimplement most of the fetching logic.

[epage]

I thought the lockfile isn't touched if you pass --no-deps.

As for config, you then have the problem of reimplementing the templating.

[Veykril]

I thought the lockfile isn't touched if you pass --no-deps.

Ah, maybe. I haven't tried that. If that is the case then we can use that to probe for that information first.

[ShoyuVanilla]

I just skimmed through the cargo code and it seems that it's not writing lockfile when we pass --no-deps option

https://github.com/rust-lang/cargo/blob/e4162389d67c603d25ba6e25b0e9423fcb8daa64/src/cargo/ops/cargo_output_metadata.rs#L35

cargo writes lockfiles when it resolves packages from registry and no-deps skips that branch.

Good news that we can also avoid current reimplementation of target-dir

[ShoyuVanilla]

I tried to handle this with #20178 but cargo_metadata crate doesn't have build_dir yet

oli-obk/cargo_metadata#297 has been merged but not yet released, so we have to wait for it