feat(css_semantic): resolve nested selectors

[togami2864]

Summary

• Added test cases for the specificity calculation
• Implement logic for resolving nested selectors name and parent selector references (&)
  • The first usecase would be 📎 Implment no-duplicate-selectors #2514

The actual result would be like

.button {
  &:hover {
    background: yellow;
  }
}

// parent selector
Selector {
    name: ".button",
    range: 0..7,
    specificity: Specificity(0, 1, 0),
}

// child selector
Selector {
    name: ".button:hover",
    range: 12..19,
    specificity: Specificity(0, 2, 0),
}

Example

1. Basic nesting:

.parent {
  .child {
    color: blue;
  }
}

Resolves to:

.parent .child {
  color: blue;
}

2. Parent selector reference (&):

.button {
  &:hover {
    background: yellow;
  }
}

Resolves to:

.button:hover {
  background: yellow;
}

3. Complex nesting with parent reference:

.header {
  nav {
    ul {
      &.primary {
        li {
          a {
            color: black;
          }
        }
      }
    }
  }
}

Resolves to:

.header nav ul.primary li a {
  color: black;
}

4. Multiple selectors:

.sidebar, .content {
  h2 {
    font-size: 18px;
  }
}

Resolves to:

.sidebar h2, .content h2 {
  font-size: 18px;
}

Test Plan

Added tests

[chansuke]

Suggested change

	for name in resolved_selectors.iter() {
	current_rule.selectors.push(Selector {
	name: name.to_string(),
	for selector_name in resolved_selectors.iter() {
	current_rule.selectors.push(Selector {
	name: selector_name.to_string(),

name is somewhat ambiguous, and selector_name would improve readability IMHO

[chansuke]

Suggested change

	fn resolve_selector(current: &str, parent: &[Selector]) -> Vec<String> {
	fn resolve_selector(current: &str, parents: &[Selector]) -> Vec<String> {

nit: parents is more accurate since it's a slice of selectors?

[chansuke]

Suggested change

	let mut resolved = Vec::new();
	if parent.is_empty() {
	return vec![current.to_string()];
	}
	for parent in parent {
	let parent = parent.name.to_string();
	if current.contains('&') {
	let current = current.replace('&', &parent);
	resolved.push(current);
	} else {
	resolved.push(format!("{} {}", parent, current));
	}
	}
	resolved
	if parents.is_empty() {
	return vec![current.to_string()];
	}
	parents
	.iter()
	.map(|parent| {
	let parent_name = &parent.name;
	if current.contains('&') {
	current.replace('&', parent_name)
	} else {
	format!("{} {}", parent_name, current)
	}
	})
	.collect()

[ematipico]

We already have a String, we shouldn't create a new one

[ematipico]

It's possible that I am late to the party, so I am sorry if this questions come too late.

Is there a particular reason we need to track String inside the semantic model? I wonder if we can avoid that and store only TextRange and syntax nodes (syntax nodes are cheaper than strings) inside the model.