Closed armandomontanez closed 3 weeks ago
Either:
I'm not sure I fully understand cc_toolchain.enabled_features
. Since it unconditionally enables a feature with no escape hatch, wouldn't the right pattern be to express the flags in that feature directly in cc_toolchain.args
?
Adding something to cc_toolchain.enabled_features
was intended to be functionally equivalent to cc_feature(..., enabled = True)
.
I used implies instead of changing cc_feature.enabled
, because that was easier to implement, and I thought it was equivalent because I didn't consider this particular use case.
FWIW, this should be a relatively simple fix - it should just be a change to legacy_converter.bzl
.
In Pigweed, we have a feature like this:
This is a feature that should default to enabled when added to the toolchain, and then dynamically be disabled by Rust rules to signal toolchain flags that should be flipped for Rust interop. When the
enabled
attribute was removed fromcc_feature
, the only way to enable a feature by default became viaimplies
(which is what is used bycc_toolchain
'senabled_features
attribute), which produces the following error: