[jdx]

A flag with setting = "key" inside a #[usage(clause)] element now sets its setting, the same as one in a flattened group. Before, the root never collected clause elements. Their bindings were missing from SETTINGS_BINDINGS, SETTING_DECLS and the settings registry. The value the user typed never reached the settings layer. A root whose only bound flags were in a clause could not use #[usage(settings)] at all: the derive said there was "no elsewhere".

#[derive(Args)]
struct Tool {
    #[usage(long, setting = "postinstall")]
    postinstall: Option<String>,
    #[usage(long, setting = "exclude")]
    exclude: Vec<String>,
    tool: String,
}

#[derive(Cli)]
#[usage(bin = "ex", settings)]
struct Ex {
    #[usage(clause)]
    tools: Vec<Tool>,
}

ex --postinstall first --exclude a node --exclude b python --postinstall last ruby now resolves postinstall = "last" and exclude = ["a", "b"]. Several clause items that give one setting contribute what a single command repeating the flag would: every entry of a list setting, in order, and the last value of any other. If a list item is not valid text, the whole list is dropped, as it already is within one item. The fold lives in a new usage_argv::spec::fold_settings_given.

Stacked on #1610.

Validation: a new conformance test, conformance/tests/derive_settings_clause.rs, covers bindings, registry types, drift, one item, several items and an item with no flags. A unit test covers the fold, and cargo test --all --all-features passes. Clippy is clean for the changed code. The one remaining -D warnings failure, in derive_settings_declared.rs, was already on the base branch.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: 2.1.316.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes derive-generated settings aggregation for a new field kind, which affects CLI config resolution wherever clauses bind settings; logic is tested but adoption paths are easy to miss.

Overview
Flags with setting = "…" on fields inside a #[usage(clause)] item are now wired into the root’s settings tables and resolved layer, matching flattened groups. The derive treats each clause field as a settings child: bindings and declarations come from the item Args type, and values are built by folding every parsed item (plus the in-progress item) through new fold_settings_given.

Multi-item clauses behave like repeating the same flags on one line: list settings accumulate entries in order; scalar settings keep the last value; mixing NotText with a list collapses the whole list to NotText. Roots that only bind settings via clause items can use #[usage(settings)] without the previous “no elsewhere” error.

Coverage adds conformance/tests/derive_settings_clause.rs for bindings, registry drift, and resolution, plus unit tests for the fold helper.

^{Reviewed by Cursor Bugbot for commit 2b494b4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Caution

Review failed

The pull request is closed.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

This PR lets flags inside clauses contribute settings to the root command.

• Flags inside clause items now feed the root CLI's settings.

No actionable issues were found.

_{Reviews (2) · Last reviewed commit: "fix(spec): collect settings bound by a f..." · Reviewed by Greptile}

[github-actions]

Instruction counts

benchmark	trend	instructions	Δ	wall (min)	Δ
markdown	▃▃▁▂▂▄▂▂▂▁█▇▆▄▅▇	266,930,202 → 266,996,926	+0.02%	46.93 → 47.32ms	+0.83%
startup	▇▇▇▇▆▇▆▇▇▆▇▇▇▇▁█	1,010,474 → 1,017,341	+0.68%	1.42 → 1.41ms	-0.81%

No instruction-count regression above 1%.

_{Only instruction counts gate. Wall clock is shown for context — on identical hardware it moves 4-20% run to run.}

_{Measured by tak — instruction-counted CLI benchmarks, stored in this repository's git notes.}

Shadow comparison

Parsing mise use -g node@20 against a shadow of mise's committed spec.
Reported, not gated: the shadow grows as the derive learns to express more, so
what to watch is the ratio rather than either column.

framework	stripped binary, bytes
usage	1250024
bpaf	2494640
clap	3100904

framework	instructions, cold parse	vs usage
usage	8295	—
clap	6313736	761x
bpaf	21909300	2641x

                                              min       p01       p10    median
usage-rs: argv -> struct                      749       750       754       776  ns
clap: build tree + parse -> struct        1240587   1244342   1253826   1270013  ns
bpaf: build parser + parse -> struct      3436630   3436630   3484832   3509174  ns

usage: argv -> struct                             762 ns      0.76 µs
clap: build tree + parse -> struct            1261273 ns   1261.27 µs
clap: parse -> struct, tree reused              49949 ns     49.95 µs
clap: build tree only                          749337 ns    749.34 µs

_{2b494b46dfa0 vs c9e2b646a282 · measured on the runner, not pushed to the history.}