[Indented syntax improvements] Dart implementation

[jamesnw]

Blocked until proposal is accepted.

• sass-spec [Indented syntax improvements] Specs sass-spec#2041

[skip sass-embedded]

[jamesnw]

@nex3 This is ready for review. Here are some questions I wanted to flag as you review. Thanks!

1. allowNewlines is set to true in some cases, like in parser* functions or in scss.dart, where the value is non-impactful. Should this usage be differentiated somehow for clarity?
2. There are some places, like in _atRootQuery, where allowNewlines is true because it is inside parentheses. I opted to not use the _inParentheses variable except for one place where the consumption did rely on it, in _supportsCondition. Would it be more idiomatic to use _inParentheses, even if the consumption is in the same function?
3. In the + include syntax, I am not supporting whitespace after the + as it can be part of a selector. This differs from the = mixin syntax- should they be the same?
4. I added paren/bracket context to almostAnyValue, with the only change being that they must be matched. That means the error for a:has(d[)] will be changed from "Expected identifer" to "Expected ]". Since almostAnyValue is used for more than selectors, should I make this functionality opt-in, dependent on a parameter? Based on the places where this is used, I don't foresee issues with bracket matching, but want to verify.

[nex3]

@nex3 This is ready for review. Here are some questions I wanted to flag as you review. Thanks!

1. allowNewlines is set to true in some cases, like in parser* functions or in scss.dart, where the value is non-impactful. Should this usage be differentiated somehow for clarity?

For classes where it's universally non-impactful, I'd define a local _whitespace() function that takes no arguments with a comment explaining that the value isn't relevant.

2. There are some places, like in _atRootQuery, where allowNewlines is true because it is inside parentheses. I opted to not use the _inParentheses variable except for one place where the consumption did rely on it, in _supportsCondition. Would it be more idiomatic to use _inParentheses, even if the consumption is in the same function?

I think how it is now is better.

3. In the + include syntax, I am not supporting whitespace after the + as it can be part of a selector. This differs from the = mixin syntax- should they be the same?

There's already an odd inconsistency here where whitespace is allowed after = but not after +, so I think it's fine to expand that to allowing newlines as well. It's possible that we should deprecate that, but it's not in-scope for this change.

4. I added paren/bracket context to almostAnyValue, with the only change being that they must be matched. That means the error for a:has(d[)] will be changed from "Expected identifer" to "Expected ]". Since almostAnyValue is used for more than selectors, should I make this functionality opt-in, dependent on a parameter? Based on the places where this is used, I don't foresee issues with bracket matching, but want to verify.

It's fine to change this error. Arguably the bracket error is clearer anyway.

[nex3]

I think we should treat ; even without a newline as the end of a statement, and just let the parser throw an error when it encounters more text afterwards.

[nex3]

Why does this trigger on wasInExpression?

[nex3]

Given that we're now explicitly parsing matching brackets here, it's probably best to throw a meaningful error here.

Note that this is technically a breaking change whether or not we throw an error here: [foo#{"]:is(bar"}) {x: y} is currently valid, but will become an error here. I think it's vanishingly unlikely that anyone is doing that, though, so it should be fine to break, but we should add a "potentially breaking bug fix" note in the changelog about it.