Repository navigation
Binding identifier should care about await/yield context #44459
Description
Bug Report
🔎 Search Terms
parsing, await, yield
🕗 Version & Regression Information
- This changed between versions 3.9.7 and now
⏯ Playground Link
💻 Code
async function foo () {
var await = 1; // should be an error, but not
}
async function bar () {
let await = 2; // error
}
function * foo1() {
var yield = 1; // should be an error, but not
}
function * bar1() {
let yield = 2; // error
}🙁 Actual behavior
BindingIdentifier in await/yield with var keyword does not throw errors.
🙂 Expected behavior
It should.
Related:
Activity
sandersn commentedon Jun 18, 2021
The problem is that
let awaiterrors are issued in the parser andvar awaiterrors are issued in the binder. Syntax errors block reporting of semantic errors.The parse errors for
let awaitare horrible, so the right fix is to allow it in the parser and issue the same grammar error as forvar awaitin the binder.Note that this will make the error disappear in plain JS files for now. I hope to fix that soon.
Kingwl commentedon Jun 22, 2021
Sorry, I'm not 100% sure what your means. Does
plain JS filesmeans js files we emitted?sandersn commentedon Jun 22, 2021
Sorry, it's a new term. 'plain JS file' means a JS file that is part of a compilation, but is not reporting semantic errors. That is, checkJS is not turned on OR explicitly off, and the file doesn't have
// @ts-checkor// @ts-no-checkin it. Plain JS files report syntax errors but not semantic errors, so moving a parser error to a grammar error makes it disappear. However, I'm planning to turn on grammar errors for plain JS files in the next release.