This avoids using maps and sets with custom equality, which are
moderately inefficient relative to built-in maps and sets on both Node
and the Dart VM. In order to make error messages continue to use the
original identifiers where possible, this updates some of them to rely
more heavily on their associated source spans for context.
In addition to being useful for users of Sass, this will make it
possible for core Sass functions to produce warnings without needing
an explicit reference to the evaluator.
This doesn't have any code changes, but I want to verify that the new
deployment infrastructure works and the only way to do that is to
actually deploy.
The automatic @charset adding is useful in general, but there are
consistently cases where it trips up naïve downstream tools. This
option makes it easier for users to control when it occurs.
This adds a --no-unicode option to disable Unicode span rendering,
decouples repl highlighting from SourceSpan.highlight, and updates
tests to work with the new error highlighting.
It also tightly scopes source spans for statements with children.
Previously, source spans for these nodes extended all the way through
any whitespace that followed the node. This led to messy-looking
multiline span highlights with dart-lang/source_span#25.
Now, StylesheetParser.children doesn't consume trailing whitespace.
Instead, we add a helper method StylesheetParser._withChildren that
parses children, creates the appropriate span, and then consumes the
trailing whitespace.
Previously, evaluator called BinaryOperationExpression.span for each
binary operation it evaluated, which in turn called spanForList() to
create a span covering both child expressions. spanForList() then
called .span for both the left and right child operations *twice*,
leading to exponential behavior.
This is now avoided in three complementary ways:
1. The evaluator avoids eagerly calling AstNode.span, instead keeping
the original AstNode until the span itself needs to be accessed.
This means that a span will only be accessed when an error actually
occurs, and then only one operation's span will be accessed.
2. BinaryOperationExpression.span now iterates through any child
operations before calling their .span methods, so it only performs
O(1) allocations.
3. spanForList() now only calls each AstNode.span once.
Getting all the tests update and the output looking nice is proving
more difficult than expected, and I want to unblock other pull
requests for Dart Sass in the meantime.
This allows us to accurately track the source spans for parenthesized
expressions, which in turn allows us to print accurate error
indications.
Adding a new class for this more accurately represents the structure
of the expression, but it also involves an extra allocation during
parsing and an extra level of nesting during evaluation which could
have a small but real performance impact.
We could alternatively add a package-internal setter for
Expression.span, and update the source span for parenthesized
expressions after they're initially parsed. However, this has its own
downsides: it adds complexity and mutability to the object model; and
many expression classes currently use lazily-generated spans, so
making them settable would require adding extra slots on those
classes.
I decided to go with the extra class because it only adds overhead
when parentheses are actually used in practice, as opposed to adding
overhead to every list/color/etc. The runtime overhead is also likely
to be mitigated if at any point we add a constant-folding step.
