tree 925e24e9effd3a9f1d33880ca11c32e33f2402e5
parent 1089574d5ccb1913ecd22a0cf0fac81e9de9e03e
author Anders Hartvoll Ruud <andruud@chromium.org> 1615549014 -0800
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> 1615550191 -0800

Handle secondary edges in custom property cycles

The cycle detection in StyleCascade is not correct. Any secondary edges
coming from a cycle are also detected as in-cycle, even if they aren't.

Explanation of how the new cycle detection works:

- AutoLock is used to "lock" a property that's currently being resolved.
  - It's instantiated at the start of ResolveCustomProperty,
    ResolveVariableReference, and ResolvePendingSubstitution. No other
    places.
  - All "lock" means is that the property we're resolving is pushed to
    CascadeResolver.stack_.
- When we're trying to resolve a var(), a cycle is detected by looking
  for a given property in that stack. If the property is found, the
  stack index is set as the cycle_start_, and the current size of the
  stack is set as the cycle_end_. The idea is that all the properties
  in the range [cycle_start_, cycle_end_) are in a cycle, and are
  therefore invalid.
- As we come back up the regular call stack, we check the InCycle flag
  to see if a (nested) variable resolution has detected a cycle, and if
  we're still inside it.

Where the old code went wrong, was that we assumed that once a cycle was
detected, we would not push anything new onto CascadeResolver.stack_
until we were out of the cycle. Hence, once a cycle was detected,
anything reachable from the start of the cycle would be detected as
in-cycle.

This is regression from the StyleCascade project (since M82), although
nobody reported the issue.

Unfortunately this exposed that two tests relied on the buggy cycle
detection. These tests have been temporarily disabled/rebaselined.

Change-Id: If7bbaad084c001c4f3349a7a4050b0a5bd33139b
Fixed: 1187282
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2749195
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#862369}