cargo install does not ignore unstable table in .cargo/config.toml file

[phil-opp]

Problem

In #6026, the behavior of cargo install was changed to ignore any.cargo/config.toml configuration in the current working directory. It seems like this behavior does not apply to the new unstable table in that config file.

Steps

1. Create a .cargo/config.toml file with the following content:

[unstable]
build-std = ["core"]

2. Try to install a crate from crates.io, e.g. cargo install bootimage.
3. This results in a -Zbuild-std requires --target error.
4. Switching to the parent directory fixes the problem because then the .cargo/config file no longer applies.

Possible Solution(s)

The unstable table should behave the same as the other .cargo/config.toml configuration keys and be ignored for cargo install. Only configuration files in the home directory and the --path directory should be considered.

Notes

Output of cargo version:

cargo 1.46.0-nightly (43cf773 2020-07-13)
release: 1.46.0
commit-hash: 43cf773
commit-date: 2020-07-13

Originally reported by @Asoftyn in rust-osdev/bootimage#64.

[ehuss]

Thanks for the report!

@bearcage do you think you can take a look at this?

[phil-opp]

I looked into this a bit and it seems like the problem is that the reload_rooted_at function only updates the Config::values field, but not the Config::unstable_flags field.

I'm not sure about the best way to fix this, but a simple solution might be to store the unstable_flags argument originally passed to Config::configure in new field (e.g. unstable_flags_cli) in the Config struct. This would make it possible to re-run the parsing of these unstable flags based on the new config location in reload_rooted_at. I'm happy to create a PR for this if this approach sounds good to you.

[ehuss]

That sounds like a good approach. Would be happy for a PR. Thanks for taking a look!

[phil-opp]

Opened a PR at #8656.

[bearcage]

Apologies for reviving an ancient thread — sorry I didn't respond to this @ehuss! This notif landed at a time I'd been auto-subscribed to a whole mess of internal repos at work and ended up declaring github-notification-bankruptcy (marking everything read).