no-redeclare not detecting redefinition of for...of variable

[oliverwoodings]

Tell us about your environment

• ESLint Version: 3.8.1 and the online demo environment
• Node Version: 6.2
• npm Version: 3

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

{
  env: {
    es6: true
  },
  rules: {
    'no-redeclare': 2,
  }
}

What did you do? Please include the actual source code causing the issue.

  for (let foo of bar) {
    const foo = 'bar'
  }

What did you expect to happen?
I expected to receive an error about line to redeclaring foo

What actually happened? Please include the actual, raw output from ESLint.
I got no warnings or errors (screenshot is of the demo tool with only the no-redeclare rule enabled):

[not-an-aardvark]

I'm not sure about this, but I think the foo declared in the loop body is actually a different variable than the one declared in the loop header. So this would fall under no-shadow instead.

If foo was referring to the same variable in both cases, I would expect your code to throw a syntax error for the same reason as this:

let foo = 1;
const foo = 1; // SyntaxError: Identifier 'foo' has already been declared

But in reality, I think the code is more similar to this:

let foo = 1;
{
  const foo = 1; // creates a new `foo` variable that shadows the other one in this block
}

[oliverwoodings]

I think what is unclear is where the block scope starts. Buble throws a parsing exception for this, which is why I ended up looking into it. I guess this is maybe an issue with spec interpretation? Either Buble or Eslint have interpreted the spec incorrectly, but tbh I'm not sure which!

[not-an-aardvark]

Well, there's actually a bug in ESLint's parser where an error isn't even thrown for the first example. I was basing what I said off the fact that the code is valid syntax in Chrome, but I can look at the spec a bit later to double-check.

[oliverwoodings]

Ah thats a fair point - Chrome is probably a better indicator than Buble for spec compliance!

[not-an-aardvark]

Closing this issue because the no-shadow rule correctly reports this case.