False positive syntax error with string template literals that call functions with object parameters named 'class' or 'function'

[ryanblock]

I noticed this potential issue in some frontend code that passes CSS classes to be rendered within a string template literals. Here's a reduced case to repro:

// This works
let opts = { class: 'hi' }
let ok = `${fn(opts)}`

// This throws
let bad = `${fn({ class: 'hi' })}`

Specifically, Acorn (ecmaVersion: 'latest') throws SyntaxError: Unterminated template (1:34).

This happens when the parameter class is included in the object passed to the function; this also occurs when the parameter name is function. I tried with a handful of other reserved JS keywords, and didn't find anything that reproduced, nor with other random parameter names.

Of course, the bad example does otherwise run:

let fn = opts => opts.class
console.log(`${fn({ class: 'hi' })}`)

Tested with Acorn 8.0.4 on Node.js 12.18.

[marijnh]

Specifically, Acorn (ecmaVersion: 'latest') throws SyntaxError: Unterminated template (1:34).

I can't reproduce this. With 8.0.4 this script outputs a parse tree:

let acorn = require("acorn")
console.log(acorn.parse("let bad = `${fn({ class: 'hi' })}`", {ecmaVersion: "latest"}))

Anything I'm missing?

[RReverser]

@ryanblock Is it possible you tried to pass the code you're describing inside another string template and forgot to escape backticks inside?

[ryanblock]

Sorry for the lag! And apologies in advance, I was apparently looking at the wrong bit of code when I reported this issue, it appears to be in tokenization. I created a reduced case repo, hopefully this helps! https://github.com/ryanblock/acorn-1001

Minor update: if instead of just spreading the results of the tokenizer on the AST, if I add the onToken param (with an array) to the parser options, I can get the token array just fine that was otherwise failing.

[marijnh]

So the code just fails to tokenize correctly when not running the actual parser? That's unfortunately how JS tokenization works—it's sufficiently difficult that you need a parser to direct it in some corner cases. Making our tokenizer 100% independent is not a goal of this library.