mirror of
https://github.com/rust-lang/cargo
synced 2024-09-19 07:41:57 +00:00
0c29d43b9a
Config file loaded via CLI takes priority over env vars ### What does this PR try to resolve? Fixes #10992 Behaviour changes: After this commit, config files loaded via CLI take priority over env vars. Config files loaded via [`config-include`] feature also get a higher priority over env vars, if the initial config file is being loaded via CLI. Cargo knows why it loads a specific config file with `WhyLoad` enum, and store in the field of `Definition::Cli(…)`. With this additional data, config files loaded via `--config <path>` get a `Definition::Cli(Some(…))`. In contrast, `--config <value>` with ordinary values become `Definition::Cli(None)`. The error message of the `Definition::Cli(Some(…))` is identical to `Definition::Path(…)`, so we won't lose any path information to debug. [`config-include`]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#config-include ### How should we test and review this PR? Reviewing commit by commit is probably fine. The first two commits adding tests to `config-cli` and `config-include`, which exercises the expected behaviour we are going to fix in the next commits. To check the precedence, set up a project with an extra config file, such as ``` # Expect to have a target-dir named `foo` CARGO_BUILD_TARGET_DIR='env' cargo c --config 'build.target-dir = "cli"' --config .cargo/foo.toml # Inside .cargo/foo.toml [build] target-dir = "foo" ``` ### Additional information This is a bit hacky IMO. I don't like leaking the path info to `Definition::Cli`. However, it is really tricky to provide information for deserialization before values get merged. |
||
|---|---|---|
| .. | ||
| build-std | ||
| testsuite | ||
| internal.rs | ||