Error Location should have a stack. #248
Comments
Merged
chriseppstein
added a commit
that referenced
this issue
Feb 19, 2020
My fix for #248 introduced a stack on error objects that allowed errors to track the location of the error within a series of imports. This turned out to be problematic because our blocks are singletons and so the errors for that block also want to be singletons. Because a block might be imported (and exported) from different blocks, the stack needed to be tracked differently. A previous commit added the CascadingError error for indicating an error was caused by some previous error and used it for block exports. In this commit, I rewrote the code to use CascadingError for block imports as well. This allowed me to stop doing weird things trying to parse a block a second time if it previously had an error -- just to get a different error instance. Building on the MultipleBlockErrors, I've updated our error reporting in a few places to describe the sequence of events that lead up to an error. The CLI now displays the root cause for an error like so: ``` error test/fixtures/basic/error.block.css Two distinct classes cannot be selected on the same element: .foo.bar At test/fixtures/basic/error.block.css:1:5 1: .foo.bar { 2: color: red; caused test/fixtures/basic/transitive-error.block.css Error in imported block. At test/fixtures/basic/transitive-error.block.css:1:1 1: @block error from "./error.block.css"; 2: error test/fixtures/basic/transitive-error.block.css No Block named "error" found in scope. At test/fixtures/basic/transitive-error.block.css:4:3 3: :scope { 4: extends: error; 5: } Found 2 errors in 1 file. ```
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When an error occurs in parsing a dependent block, the error location needs to include the code locations of all the
@blockcommands that got to that block from the entry source file.The text was updated successfully, but these errors were encountered: