clap_derive can parse arbitrary Rust code, which is not always necessary and costs compile time #5657
Open
2 tasks done
Labels
A-derive
Area: #[derive]` macro API
C-enhancement
Category: Raise on the bar on expectations
M-breaking-change
Meta: Implementing or merging this will introduce a breaking change.
S-waiting-on-decision
Status: Waiting on a go/no-go before implementing
Please complete the following tasks
Clap Version
4.5.15
Describe your use case
I have a workspace where I care a little too much about build times (e.g., for iterating on cargo profile settings / RUSTFLAGS) and use a handful of syn-based custom derives, including clap's. Unlike most other derives I've seen (and unlike all others I'm using in this workspace), clap_derive enables syn's "full" feature that enables parsing arbitrary expressions, items, etc. instead of just the parts that are usually needed for derives. This has negative effects for compilation time (cc #2037):
cargo test
, out of ca. 10s total) because there happens to be enough independent work for the number of CPUs I have and another critical path in the schedule. It matters more in smaller workspaces (or with more CPUs, presumably), e.g., for the git-derive example by itself, disabling syn/full reduces clean dev builds from 5s to 4.3s on my machine.Describe the solution you'd like
Ideally, the syn/full feature could just be removed completely (cc #4784). clap_derive does build when the feature is removed (some care is needed while testing this because several dev-dependencies in clap's workspace enable it anyway), but some uses of the derives break because syn can't parse some kinds of expressions without the "full" feature. I don't have a full list of what's affected, but at least it causes an error for
arg(num_args = n..=m)
as used e.g., in the git-derive example. From my understanding of how clap_derive works, I think it's always possible to work around this by extracting those expressions into separate constants, but that's still annoying and a breaking change.On the other hand, many simpler expressions (literals, identifiers, paths, binary operators, taking references, etc.) don't seem to be affected. Case in point, my aforementioned workspace works just fine if test a patched version of clap_derive minus syn/full via
[patch.crates-io]
. So instead I propose a new feature, enabled by default, flag that controls whether syn/full is enabled. Those who care to fiddle around with feature flags and find that disabling this one doesn't break their project can do so, while everyone else is unaffected.Alternatives, if applicable
In addition to or instead of a new feature flag, the breaking change of not enabling syn/full (by default or ever) could be rolled into clap v5. But I don't seriously want to propose this without fully understanding the consequences. Are there any clap features that would become annoying or even impossible to use via the derive API without syn/full? For example, is there an ergonomic alternative for
num_args = n..=m
?Additional Context
No response
The text was updated successfully, but these errors were encountered: