Repository navigation
Catchless try statement linter crash #97
Description
try:
yGives
TypeError: Cannot read property 'empty' of null
at CodePathState.popTryContext (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/code-path-analysis/code-path-state.js:755:22)
at processCodePathToExit (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:481:19)
at CodePathAnalyzer.leaveNode (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:651:9)
at nodeQueue.forEach.traversalInfo (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/linter.js:862:28)
at Array.forEach (<anonymous>)
at runRules (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/linter.js:856:15)
at Linter._verifyWithoutProcessors (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/linter.js:992:31)
at preprocess.map.textBlock (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/linter.js:1043:35)
at Array.map (<anonymous>)
at Linter.verify (/Users/wcj/dev/lightscript-minimal-node/node_modules/eslint/lib/linter.js:1042:42)
Essentially, eslint is expecting every try to have a catch or finally, since that's the rule in JS. This part of the linter is not easily extensible, so the solution probably involves doing an ast transform in the parser to add a faux catch block.
Activity
wcjohnson commentedon Oct 2, 2018
See: eslint/eslint#10823
wcjohnson commentedon Oct 3, 2018
Upon evaluating this, I think this is a parser bug. Technically the ESTree spec says a
TryStatementneeds either a catch or finally, so when the parser emits one without that, it's emitting faulty nodes.So, will resolve by having the parser emit an
LscTryStatementif there is no catch or finally, then just transform that into a regular try statement in the compiler.test: Add fixture for `try` crash