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.
If a non-partial stylesheet is next to a partial with the same name,
canonicalizing the source URL would fail. We don't really need to
canonicalize that URL anyway, though, since it's only used for import
loops and such a loop will reload and rerun the entrypoint anyway.
We were resolving URLs relative to the canonical URL rather than the
original URL, which broke importers for which those were different,
like the package importer.
Closes#334
