Skip generating unnecessary @supports#878
Conversation
| SupportsCondition::Declaration { property_id, value } => match property_id { | ||
| PropertyId::Color => Some(match value.as_ref() { | ||
| COLOR_P3_SUPPORTS_CONDITION => Features::P3Colors | Features::ColorFunction, | ||
| COLOR_LAB_SUPPORTS_CONDITION => Features::LabColors, |
There was a problem hiding this comment.
This would only work if the value is an exact match. Perhaps a future enhancement would be to attempt to parse the value, and extract the features from that. For example, if any lab() color was used, set that feature rather than only lab(0% 0 0)
There was a problem hiding this comment.
Yeah, it would be nice to expand this detection in future.
src/targets.rs
Outdated
| #[derive(Debug)] | ||
| pub(crate) struct TargetsWithSupportsScope { | ||
| input_targets: Targets, | ||
| supports_scope_features: IndexSet<Features>, |
There was a problem hiding this comment.
You could probably get away with just a Vec here. Since Features is a bit set, it should only accumulate new items the deeper you go. So you could track each @supports you enter in a stack, and modify current in place:
fn enter_supports(&mut self, features: Features) -> bool {
if features.is_empty() || self.current.exclude.contains(features) {
// Already excluding all features
return false;
}
self.stack.push(supported);
self.current.exclude.insert(features);
true
}
fn exit_supports(&mut self) {
if let Some(last) = self.stack.pop() {
self.current.exclude.remove(last);
}
}Then you wouldn't need to iterate over the stack each time and could avoid the hashing cost of IndexSet.
Do you think this would work or am I missing something?
There was a problem hiding this comment.
That's true! I updated the code to use Vec.
I added this line to make cases like what I added as a test case work.
394930a#diff-05702e78430359853e5b38404035fa394540368bee185a2cdc936a62b9cd65b0R271
| } | ||
|
|
||
| #[derive(Debug)] | ||
| pub(crate) struct TargetsWithSupportsScope { |
There was a problem hiding this comment.
Should this just be part of Targets?
There was a problem hiding this comment.
Do you mean putting the fields in Targets and making it stateful?
|
Sorry for the delay! I implemented improved detection of used features by parsing the value in d398c1b. That also applies the exclusions during printing so that features like |
|
Thanks! That sounds great. It'd be great if I can have your input on #880, too. |
This PR introduces
TargetsWithSupportsScopestruct that tracks the parent@supportss. This struct hascurrentfield that contains the current target that is based on thetargetoption and the parent@supportss.This makes lightningcss to skip generating unnecessary
@supports.closes #711