Profiles are configurable: opt-level, lto, codegen-units, panic, strip and debug-assertions, through plugin config mapped onto Please's build configs.
cargo also has [profile.*.package.<name>], which sets those per crate rather than per build. The common use is compiling one expensive dependency with optimisation while the rest of a debug build stays unoptimised.
There is no equivalent here.
What it would take
A per-declaration override on rust_repo, carried through the lock the way features and platforms already are, and applied at compile time. The mechanism for per-crate data in the lock exists, which is most of the work.
Worth weighing first
This is rarely used in cargo, and the plugin has shipped without it. Filed so the gap is recorded rather than because it is wanted; if nobody asks, closing it as on-demand is a reasonable outcome.
How you would know
A crate compiled with a different opt-level from the rest of the build, verified in the rustc invocation.
Profiles are configurable: opt-level, lto, codegen-units, panic, strip and debug-assertions, through plugin config mapped onto Please's build configs.
cargo also has
[profile.*.package.<name>], which sets those per crate rather than per build. The common use is compiling one expensive dependency with optimisation while the rest of a debug build stays unoptimised.There is no equivalent here.
What it would take
A per-declaration override on
rust_repo, carried through the lock the way features and platforms already are, and applied at compile time. The mechanism for per-crate data in the lock exists, which is most of the work.Worth weighing first
This is rarely used in cargo, and the plugin has shipped without it. Filed so the gap is recorded rather than because it is wanted; if nobody asks, closing it as on-demand is a reasonable outcome.
How you would know
A crate compiled with a different opt-level from the rest of the build, verified in the rustc invocation.