Parsing Error "Unrecognised input" for color operations with color names #2124

[SomMeri]

Named colors inside expressions are will be parsed as colors.

[SomMeri]

Linking original issue: #2124

[seven-phases-max]

Btw., would not it make sense to add more tests for ambiguous (especially with -sm=off) expressions like:

foo {
    0: 0 -red;  
    1: 1 - red; 
    2: -red * 2;
   @3: -red;

    &-bar@{3} {x: y}
}

[SomMeri]

I was confident, but -red * 2; really failed. So, do not merge yet.

[seven-phases-max]

It's just also similar quite not always predictable story with hex values, for example. So I'm just a bit concerned of more side-effects this could add.

---

Technically for -red * 2 I'd say it should fail as it can be considered as -webkit-fnord * 2. Thus it's not possible to decide if -red is actually a negated red or just a regular CSS identifier. It's tricky, obviously we do know there's no (and never will be?) such thing as -aqua in CSS, so we could probably assume it as an expression. On the other hand I suspect this would also mean that every identifier (in values/variables) beginning with - (e.g. -webkit-gradient) first has to be tried to be parsed as -color, and only if this fails it falls back to -ident, but this -> bad performance.

Thus I probably would left -red as-is (i.e. -red * 2 -> error) especially since for such ambiguous expressions a workaround will be as simple as red * -2 (or color(red) * -2 as it is now for #2124 in general).

---

P.S. e.g. just like -round(2.3) results in -round(2.3) currently, not -2.

[SomMeri]

Since color-0: 0 -red;compiles into color-0: 0 -red;, then I think -red * 2 should compile into -red * 2 instead of failing.

[SomMeri]

Never mind, identifier multiplied by number fails no matter what, so it is better to keep it that way. If it wants to be changed, it would be different issue anyway. So I will just add test you suggested without that.

[seven-phases-max]

Never mind, identifier multiplied by number fails no matter what, so it is better to keep it that way. If it wants to be changed, it would be different issue anyway.

Yep.

[seven-phases-max]

Investigating #2802. Indeed that's mysterious. W/o autoCommentAbsorb = false;
this property: yes /* comment */; causes infinite parser loop (why?),
but otherwise property: red /* comment */; is obviously expected to fail.
No ideas how to fix this so far.

[seven-phases-max]

Never mind, I found another workaround on top of that. Now just polishing a performance for the fix.

[SomMeri]

I added parserInput.autoCommentAbsorb = false because the comments were either doubled or swallowed without it (I do not remember which one).