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.
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.
When a stylesheet is imported, the parsed stylesheet object is cached
based on its canonical URL. However, the stylesheet.span.sourceUrl was
based on the text of the import that was used to load that stylesheet.
The idea was to make the source URL in stack traces look nicer, but it
meant that relative URLs could be resolved based on the old importer's
URL before being sent to the new importer, which caused bugs.
Now stylesheet.span.sourceUrl is always the canonical URL of the
stylesheet, and thus safe to cache. We then use the import cache to
convert the canonical URL to a human-friendly URL at the point at
which we generate stack traces.
This also deprecates support for relative canonical URLs. The
semantics of these URLs were always unclear, and with the new change
in import internals the old behavior doesn't make much sense. It's
preserved for backwards-compatibility, but deprecated.
