fix: rustc cfg crash when directory is deleted

[Wilfred]

rustc --print cfg can be run in any directory, but the command will error if the directory does not exist.

This is more noticeable when working on a large monorepo with a rust-project.json, but it can occur in cargo projects too.

I haven't been able to reproduce this many times, but it seems to be due to switching commits before/after a directory is created.

The rust-analyzer log looks like this:

2026-03-13T06:43:13.1075102-07:00  WARN failed to get rustc cfgs e=unable to fetch cfgs via `cd "/home/wilfred/monorepo/old_dir/foo/" && RUSTUP_AUTO_INSTALL="0" "/home/wilfred/.cache/dotslash/obj/cas/35/b8b890939206aaabc7b768fd66ad4d2c/extract/tar.zst/bin/rustc" "--print" "cfg" "-O"`

Caused by:
 0: cd "/home/wilfred/monorepo/old_dir/foo/" && RUSTUP_AUTO_INSTALL="0" "/home/wilfred/.cache/dotslash/obj/cas/35/b8b890939206aaabc7b768fd66ad4d2c/extract/tar.zst/bin/rustc" "--print" "cfg" "-O" failed

[ChayimFriedman2]

It matters in case of overrides, I think.

[Wilfred]

You mean an override with rustup changing the tool chain version? Yeah, that's the only case I can think of where the working directory matters.

Another approach would be to look at the parent, grandparent etc directory until we have a directory that exists. That would help if e.g. the grandparent directory has the tool chain override.

[ChayimFriedman2]

When we're unable to run it, it's temporary and after rust-project.json changes will be notified we will load it correctly, right? So the right solution is to ignore the project. But isn't that what we do now, except we also warn?

[Veykril]

It does matter where we run this command at least when we end up using cargo due to .cargo/config.toml lookup which can affect some things here. For plain rustc I am not sure, it probably doesn't matter

[Veykril]

I am a bit confused as to how we end up calling this with a non existing working directory though, that means we have a project loaded in a non existing directory no?