This codifies in types the constraint that only the evaluator should
modify CSS nodes. It also makes it possible to create non-mutable
classes that don't need to care about stuff like tracking parent nodes.
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.
- Documentation comments are simply identified by starting with a triple-slash "///".
- Adjacent comments in indented syntax are now coalesced into a single comment.
This introduces two changes:
1. It changes the epsilon within which two numbers are considered
equal to be an order of magnitude smaller than the numeric
precision. Ruby Sass has always done this, and Dart Sass should
have but did not until now.
2. It parses the component of a number after the decimal point using
double.parse() to avoid accumulating floating point errors.
These can be passed as an ImportCache now, so they make the API more
confusing for relatively little benefit.
This also changes the const AsyncImportCache.none field to a non-const
AsyncImportCache.none() constructor. The const field didn't make sense
for a couple reasons: first, it wouldn't use a user's custom logger;
and second, it couldn't cache any relative imports, which were still
possible when the initial file was loaded from disk.
With #506, we're pushing the master branch to the Bazel repo. But
we're actually committing to a detached HEAD, rather than the master
branch. This pushes the current HEAD instead.
Closesbazelbuild/rules_sass#61
This flag wasn't being respected, so all of these identifiers were de
facto case-insensitive. Changing that now would be breaking, and it's
probably better to make them case-insensitive anyway since CSS
identifiers are.
I missed this as part of #509. It doesn't actually cause any problems,
because we don't use the expression-visiting functionality, but it
could cause issues for the linter.
Always include the error location in JS error messages
I was trying to match Node Sass's behavior by having Error.formatted
property have more detail than Error.message, but our errors rely on
source snippets for context so this just ended up making them
confusing.
