Context
shlex is used in one place in cc-rs: parsing *FLAGS environment variables (CFLAGS, CXXFLAGS, ARFLAGS, RANLIBFLAGS) when shell-style splitting is opted into via Build::shell_escaped_flags or CC_SHELL_ESCAPED_FLAGS=1. The single call site is in Build::envflags.
Reasoning
cc-rs sits in the build-dep closure of nearly every Rust crate that touches native code, so any transitive dep is effectively part of the supply chain for a large portion of the ecosystem.
Of the ~1,300 LOC in shlex 1.3.0, cc-rs only exercises the iterator (~120 LOC). The remaining ~700 LOC is the quoting-side API, which cc-rs never calls. Vendoring the small subset cc-rs actually uses would:
- Remove
shlex from the dep graph of every crate that uses cc as a build-dep.
- Shrink the audit surface to code that lives in this repo.
- Avoid pulling in API surface (the
Quoter/escape side).
The trade-off is taking on ~120 LOC of vendored parsing code (with attribution preserved).
Would the maintainers be open to this? If so, I can put up a PR.
Context
shlexis used in one place in cc-rs: parsing*FLAGSenvironment variables (CFLAGS,CXXFLAGS,ARFLAGS,RANLIBFLAGS) when shell-style splitting is opted into viaBuild::shell_escaped_flagsorCC_SHELL_ESCAPED_FLAGS=1. The single call site is inBuild::envflags.Reasoning
cc-rs sits in the build-dep closure of nearly every Rust crate that touches native code, so any transitive dep is effectively part of the supply chain for a large portion of the ecosystem.
Of the ~1,300 LOC in
shlex1.3.0, cc-rs only exercises the iterator (~120 LOC). The remaining ~700 LOC is the quoting-side API, which cc-rs never calls. Vendoring the small subset cc-rs actually uses would:shlexfrom the dep graph of every crate that uses cc as a build-dep.Quoter/escape side).The trade-off is taking on ~120 LOC of vendored parsing code (with attribution preserved).
Would the maintainers be open to this? If so, I can put up a PR.