config file read twice when $CARGO_HOME is a symlink

[VAWVAW]

Problem

Cargo will read from the current directory upwards (after resolving symlinks) and search for all .cargo/config.toml file. After that, it will read $CARGO_HOME/config.toml.

If $CARGO_HOME/config.toml was previously loaded, it is not loaded twice unless any directory in its location is a symlink.

Steps

on unix:

1. mkdir -p a/b
2. ln -s a c
3. mkdir a/.cargo
4. echo "[build]\nrustdocflags = [\"--default-theme=dark\"]" > a/.cargo/config.toml
5. cd a/b
6. CARGO_HOME=../../c/.cargo cargo doc
7. notice (with strace or by having a project at a/b) that the config file is read twice and the build fails

Possible Solution(s)

Cargo should also calculate the realpath of $CARGO_HOME/config.toml before comparing it to the current dir (for which the realpath is calculated).

Notes

No response

Version

cargo 1.89.0 (c24e10642 2025-06-23)
release: 1.89.0
commit-hash: c24e1064277fe51ab72011e2612e556ac56addf7
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.16.0 (sys:0.4.80+curl-8.12.1 system ssl:OpenSSL/3.6.0)
os: NixOS 25.11.0 [64-bit]

and

cargo 1.92.0-nightly (367fd9f21 2025-10-15)
release: 1.92.0-nightly
commit-hash: 367fd9f213750cd40317803dd0a5a3ce3f0c676d
commit-date: 2025-10-15
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: NixOS 25.11.0 [64-bit]

[epage]

Just some quick notes

We load config from CARGO_HOME at

cargo/src/cargo/util/context/mod.rs

Lines 1637 to 1644 in 8d3e73f

	// Once we're done, also be sure to walk the home directory even if it's not
	// in our history to be sure we pick up that standard location for
	// information.
	if !seen_dir.contains(home) {
	if let Some(path) = self.get_file_path(home, "config", true)? {
	walk(&path)?;
	}
	}

We generally avoid canonicalize. We did use it for a build-dir template variable to resolve symlinks which led to #16110. The workaround we talked about there is to use canonicalize(path).unwrap_or(path).

[fahdfady]

@rustbot claim