-
Couldn't load subscription status.
- Fork 2.7k
feat: support array of any types in Cargo config #16103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
57ee900 to
0850805
Compare
| Caused by: | ||
| expected string but found integer at index 0 | ||
| [ERROR] invalid type: integer `1`, expected a string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the error message regression that the next commit want to deal with
0850805 to
48fed23
Compare
src/cargo/util/context/de.rs
Outdated
| seed.deserialize(de) | ||
| .map_err(|e| { | ||
| // This along with ArrayItemKeyPath provide a better error context of the | ||
| // ConfigValue definition + the key path within an array item that native | ||
| // TOML key path can't express. For example, `foo.bar[3].baz`. | ||
| key_path.push_index(i); | ||
| e.with_array_item_key_context(&key_path, definition) | ||
| }) | ||
| .map(Some) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it indeed fixes the this might the less good approach dealing with the diagnostic issue in general. The current approach only track the key path for array items when deserialzation fails. If caller requests for Vec<Value<String>> and performs post-deserialization validation, the key path info is missing for a better error context.
We might want to add an extra optional field array_item_path to Value<T> to preserve the information though. That is why I feel like may we should put off the second half of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think more about it. The other option is doing nothing and staying with the current collect-on-error implementation. The caller should be able to compute the index of an item given it has the full picture of the array.
4fae025 to
930baee
Compare
930baee to
98af008
Compare
This demonstrates what we have supported today: no nested arrays
Actually it is not supported yet. Will do in the next few commits.
Only add the support to TOML-based Cargo config. Environment variables still only supports array of strings. `-Zadvanced-env` is not yet supported. There is a regression in `cargo_alias_config::alias_malformed_config_list` that the key path error report is missing. This may require a revamp over ConfigKey.
98af008 to
4541603
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Update cargo submodule 11 commits in 344c4567c634a25837e3c3476aac08af84cf9203..6c1b6100343691341b9e76c5acc594e78220f963 2025-10-15 15:01:32 +0000 to 2025-10-28 16:27:52 +0000 - feat(build-analysis): JSONL-based logging infra (rust-lang/cargo#16150) - feat: support array of any types in Cargo config (rust-lang/cargo#16103) - test(git): add more fetch-index backend interop (rust-lang/cargo#16162) - feat(git): support shallow fetch for Git CLI backend (rust-lang/cargo#16156) - Fix mdman to not incorrectly strip `<p>` tags (rust-lang/cargo#16158) - chore(triagebot): enable range-diff and review-changes-since (rust-lang/cargo#16152) - Avoid specifying which version will change behavior (rust-lang/cargo#16153) - Make shell completion variables private. (rust-lang/cargo#16144) - More warning conversions (rust-lang/cargo#16143) - Bump openssl-src to 300.3.5.4+3.5.4 (rust-lang/cargo#16140) - build: remove duplicate dependency, consolidate over unicode-ident (rust-lang/cargo#16137)
What does this PR try to resolve?
This adds the support of array of any types in Cargo config.
The motivation of this is mostly from the proposed
-Zconfig-includesyntax (#7723 (comment))which before this Cargo only supported array of string.
Some design decisions:
CARGO_*env support added — Only the--configCLI and file-based configuration start supporting array of any types.CARGO_*config environment still doesn't. The only type you can set through environment variable are still primitive types. For advanced env usage, we left it as follow-up to deal with in-Zadvanced-envcargo config getnow prints inline array/tables for array of nested array/tables.fixes #16111
How to test and review this PR?
Starting from the fifth commit, those changes are for handling diagnostic regression, as now
Config::from_tomlaccepts any types and the invalid type error is delayed from the "TOML->ConfigValue" deserialization to "ConfigValue->Target" Type deserialization. Not sure if we should split it to a separate PR, but the solution here I admit is a bit nasty.