This also adds a Value.tryMap() function, which was useful for
implementing this and may be more generally useful to users as well.
See sass/sass#2836
See sass/sass-spec#1560
This also adds a Value.tryMap() function, which was useful for
implementing this and may be more generally useful to users as well.
See sass/sass#2836
See sass/sass-spec#1560
This also adds a Value.tryMap() function, which was useful for
implementing this and may be more generally useful to users as well.
See sass/sass#2836
See sass/sass-spec#1560
* Move Node tests on Windows to Travis
Appveyor is flaky and can't be restarted by all team members, so moving
everything to Travis is preferable if we can get it to work.
* Actually use latest stable Node
This should also workaround the issue with lts/* not working on
Windows.
* Use npm.cmd instead of raw npm on Windows
* Use p.prettyUri() for Node API tests
Co-authored-by: Natalie Weizenbaum <nweiz@google.com>
Doing this for variable *nodes* was breaking in extremely specific
circumstances:
* A null node is passed into setVariable() and, if source maps are
enabled, recorded in _variableNodes.
* Later on, getVariableNode() is called for that variable. Because
that variable's node is null, it calls
_getVariableNodeFromGlobalModule() even though the variable is
actually defined.
* _getVariableNodeFromGlobalModule() sets _lastVariableIndex to 0 on
the assumption that the variable is undefined, which turns out to be
incorrect in this specific case.
The next commit will fix the issue where a null node can be passed
into setVariable() when source maps are enabled, but it makes more
sense to assign the variable index to 0 in the variable access anyway,
since it happens first and isn't skipped when source maps are
disabled.
This also adds a test to verify that all YAML files are valid. Travis
won't run tests at all if its YAML is invalid, but this way Appveyor
can warn about broken Travis config and vice versa, and a local test
run will warn about either.
For any @errors encountered in mixins or functions, use the call-site
(instead of the @error rule) as the span printed in the error message.
Closes#474
See sass/sass-spec#1494
We now wrap _withStackFrame() around wider sections of code, including
_loadStylesheet() which handles parse errors, so that the @use/@import
stack frames are available.
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.
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.
- 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.
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
If a warning or debug message is emitted, and then the line errors,
a simpler error message is output instead of highlighting the bad
input in the original line.
Errors are now logged w/o the Sass stack trace and with arrows
pointing to the piece of the input that caused the error.
The bad input will also be highlighted in red if color is enabled.
Adds tests for error logging, both with and without color.