Regression: the target/rust-analyzer directory ignores .cargo/config.toml

[ia0]

rust-analyzer version: N/A (I'm assuming this is VSCode specific)
rustc version: rustc 1.90.0-nightly (f26e580 2025-06-30)
editor or extension: Emacs (using eglot for LSP)
relevant settings:

• cargo.buildScripts.useRustcWrapper is false (due to Rust-analyzer is corrupting the cargo .fingerprint cache #14722)
• diagnostics.enable is false

code snippet to reproduce:

# /tmp/bug/.cargo/config.toml
[build]
target-dir = "target"

/tmp/bug % cargo new foo
/tmp/bug % edit foo/src/main.rs
/tmp/bug % find . -name target
./target
./foo/target
/tmp/bug % tree foo/target
foo/target
└── rust-analyzer
    └── metadata
        ├── sysroot
        │   └── Cargo.lock
        └── workspace
            └── Cargo.lock

5 directories, 2 files

It seems target/rust-analyzer is a new thing.

[ia0]

Seems related to:

• Cached offline use regression since lock file copying was implemented #20115
• Rust-analyzer creates target/rust-analyzer/metadata directories since latest update #20067
• Creating target director in crate folder with target-dir set in .cargo/config.toml #20070
• Honor build.target-dir from .cargo/config.toml #18838

[ShoyuVanilla]

rust-analyzer version: N/A (I'm assuming this is VSCode specific)

No it doesn't. Of course, rust-analyzer vs-code extension has its version but rust-analyzer itself also has its own version.
You can check it with rust-analyzer --version and I guess you have rust-analyzer in your PATH since you're using eglot.

And I think this issue has been fixed with #20072 but to be sure your version information would be a great help.

[ronnodas]

I'm not sure it was fixed in #20072. As I also mentioned in #20070, setting target-dir = dirname makes cargo use ~/dirname, while RA seems to be using <project root>/dirname.

[ShoyuVanilla]

I'm not sure it was fixed in #20072. As I also mentioned in #20070, setting target-dir = dirname makes cargo use ~/dirname, while RA seems to be using <project root>/dirname.

Yes, I saw your comment and I guess it would be fixed with #20178, which I just issued 😄
The problem is that we are currently reading .cargo/config.toml values to get target-dir and since we cannot discern <workspace root>/.cargo/config.toml from <cargo home>/config.toml we are using wrong assumption for the later.

#20178 reads them from cargo metadata command, which gives absolute path, so no such problem.

[ia0]

You can check it with rust-analyzer --version

Ah that's what was meant. Then it's the same as rustc but the commit hash is even more truncated.

And I think this issue has been fixed with #20072

No, I tried again with the latest nightly and the issue is still present:

rustc 1.90.0-nightly (e3843659e 2025-07-04)
rust-analyzer 1.90.0-nightly (e384365 2025-07-04)

I believe #20072 was fixing another target-dir related issue. In particular, this issue is about target/rust-analyzer, not the compilation artifacts.

Yes, I saw your comment and I guess it would be fixed with #20178

Maybe I should try to use to compile rust-analyzer at that version. Let's see if I get the time.

[ia0]

Also, did anyone tried to reproduce the issue from the original comment? That's really just a few commands.

[ia0]

I also tried to compile rust-analyzer from source at 2 different commits:

• rust-analyzer 0.0.0 (3816d0ae53 2025-07-04) (current master) has the issue
• rust-analyzer 0.0.0 (71a70f0db7 2025-07-05) (merge commit of chore: Cleanup cargo config queries #20178) fixes the issue

So I can confirm that #20178 fixes this issue.

[ShoyuVanilla]

First, to be clear, rust-analyzer bundled with rust toolchain is not the newest one, even if you have installed it with newest nightly toolchain, as rust-lang/rust includes it as a subtree and it is not synced on every commits.
You can see this in here https://github.com/rust-lang/rust/tree/master/src/tools/rust-analyzer - it's five days ago.

But of course it's newer than the #20072 so it seems that your issue is not fixed with it.

Also, did anyone tried to reproduce the issue from the original comment? That's really just a few commands.

Sorry for not trying to reproduce your case.
In first glance, it seemed to be an already resolved issue and I didn't know which rust-anaylzer version were you on, so I just said "Oh, it probabily has been fixed before" 😅
As you said, it's just few steps but I myself was using weeks old version and I was just too lazy to install and have it on my PATH and test it, few more steps.

[ia0]

Thanks a lot @ShoyuVanilla ! I confirm this is now fixed in the rust-analyzer component of the latest nightly.