Make `.cargo/config` deprecation warnings silent

[ijackson]

Problem

I want to be able to run cargo 1.31 and have it respect my ,.cargo/config.

There seems to be no way to achieve this without causing recent cargo to issue a warning.

Steps

1. Try: config is a file, config.toml doesn't exist

warning: `/home/rustcargo/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`

(Note that the phrase "symlink X to Y" is ambiguous. Does it mean make X a symlink to Y, or vice versa?)

1. Try: config is a file; config.toml is a symlink to it

warning: both `/home/rustcargo/.cargo/config` and `/home/rustcargo/.cargo/config.toml` exist. Using `/home/rustcargo/.cargo/config`

2. Try config.toml is a file, config is a symlink to it

warning: both `/home/rustcargo/.cargo/config` and `/home/rustcargo/.cargo/config.toml` exist. Using `/home/rustcargo/.cargo/config`

Possible Solution(s)

Check to see if one of the files is a link to the other. If so, don't issue the warning about both files existing.

The "one file is a link to the other" check should be done with stat and comparing st_dev and st_ino. (AIUI Windows doesn't have symlinks in the same way so we don't need to do this check there.)

Notes

This is a blocker for me upgrading the pinned nightly used by CI tests for derive-deftly, because I have UI tests that check for the precise stderr output. Right now, those tests always produce polluted output in my local environment.

This is happening to me with +nightly-2024-03-14. I can't easily try a more recent version because my rustup is completely broken due to rust-lang/rustup#3737

Version

rustcargo@zealot:~/.cargo$ cargo -vV
cargo 1.77.0-beta.5 (837c09f04 2024-02-16)
release: 1.77.0-beta.5
commit-hash: 837c09f04022352c26cf445f37492709922b24ef
commit-date: 2024-02-16
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.5.0-DEV (sys:0.4.70+curl-8.5.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian 10 (buster) [64-bit]
rustcargo@zealot:~/.cargo$

[weihanglo]

This is a blocker for me upgrading the pinned nightly used by CI tests for derive-deftly, because I have UI tests that check for the precise stderr output. Right now, those tests always produce polluted output in my local environment.

I would suggest not to check Cargo's stderr, as it is generally for human and subject to change at any time. That being said, #12235 is a way out, and we've landed the initial version of the linting system in #13621.

Check to see if one of the files is a link to the other. If so, don't issue the warning about both files existing.

Personally I wouldn't add more complexity to the logic there until we have a lint for it. I don't speak for others.

[ijackson]

Personally I wouldn't add more complexity to the logic there until we have a lint for it. I don't speak for others.

It seems to me that the current situation is simply wrong. cargo prints a warning, and suggests a resolution, but then it also prints a warning about the suggested resolution.

cargo should not suggest a resolution that isn't effective. If there is another resolution for this situation, cargo should suggest that.

I also don't think #12235 is going to be the answer because it's a year old and obviously isn't going to happen soon.

The current situation is a regression.

I would suggest not to check Cargo's stderr, as it is generally for human and subject to change at any time.

That's all very well, but I need to test the stderr output of a proc macro, which can't realistically be done without invoking cargo and rustc.

If I don't get a better resolution I guess I'm going to be writing horrible code to filter out this nuisance warning with regexps, or something. I would very much like to avoid that.

[ijackson]

I went to fix this. UTSL, and I find

                // We don't want to print a warning if the version
                // without the extension is just a symlink to the version
                // WITH an extension, which people may want to do to
                // support multiple Cargo versions at once and not
                // get a warning.
                let skip_warning = if let Ok(target_path) = fs::read_link(&possible) {
                    target_path == possible_with_extension
                } else {
                    false
                };

which is buggy. I will fix it.