-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Support a crate flag to recommend optimization #8501
Copy link
Copy link
Open
Labels
A-profilesArea: profilesArea: profilesC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Description
Metadata
Metadata
Assignees
Labels
A-profilesArea: profilesArea: profilesC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Type
Fields
Give feedbackNo fields configured for issues without a type.
As a further enhancement to #8500 , we'd like to have an option in
Cargo.tomlfor a library crate to specify that it should almost always be optimized unless specifically requested otherwise.This would be for crates like phf or lalrpop or munkres, where the optimization level makes a massive performance difference.
We could pay attention to this option whenever we're building with a "default" opt-level of 0, such as for build-dependencies with #8500 , or for dev/test builds. If a crate explicitly says that the dependency should use opt-level 0, we would do that, but if we're only using opt-level 0 because of a built-in default, then a dependency's
Cargo.tomlspecifying to optimize it would be respected.I'd suggest an option like
default-optimized = true.