Catchless try statement linter crash

[wcjohnson]

try:
  y

Gives

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.

[wcjohnson]

See: eslint/eslint#10823

[wcjohnson]

Upon evaluating this, I think this is a parser bug. Technically the ESTree spec says a TryStatement needs 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 LscTryStatement if there is no catch or finally, then just transform that into a regular try statement in the compiler.