TypeScript wrong highlighting when using if within for

[aeschli]

From @igabesz on November 26, 2015 11:26

TypeScript highlighter interprets if calls within a for loop as function definitions if the if has middle parameter and brackets. The interpretation starts failing in the for loop for the last parameter.

Not the consequence of installed extensions.
Highlighting fails for other color themes as well, not only Monokai.

// OK
for (var i=0;; i++) {
    if (i===0) {}
}
// Partially wrong, see for loop 3rd parameter
for (let i=0; i<5; i++)
    if (i===0) {}
// Wrong
for (var i=0; i<5; i++) {
    if (i===0) {}
}
// Wrong
for (let i=0; i<5; i++) {
    if (i===0) {}
}
// Wrong
for (; i<5;) {
    if (i===0) {}
}

Copied from original issue: microsoft/vscode#704

[aeschli]

From @igabesz on November 26, 2015 11:34

This can get really ugly for more complex cases. (Logic mostly omitted.)
Highlighting works fine again after removing the middle parameter of the for cycle.

[aeschli]

From @igabesz on November 26, 2015 11:56

OK, messing with this a little more I came across that highlighting breaks if there is a variableName< text in the middle parameter of for. I think it's something with the parsing of templates.

• Not happens if there is whitespace, e.g. variableName <
• Not happens for funcCall(variable)<
• Not the < operator triggers the error, variableName<< also works

Also the consequences are not affecting only to the for body, although they are more limited afterwards.

[aeschli]

From @egamma on November 26, 2015 14:52

The TypeScript Sublime plugin renders this correctly.
Should we update the textmate bundle with the one from Microsoft/TypeScript-TmLanguage.

[aeschli]

I verified that we are using the latest version from https://github.com/Microsoft/TypeScript-TmLanguage.
Installing that same grammar file also in Sublime shows there is the same bug:

VS Code on the left - Sublime 3 on the right:

[DanielRosenwasser]

@aeschli should we close this as fixed?

[aeschli]

To me it looks like a bug in the grammar. Do you disagree?

[DanielRosenwasser]

Sorry, I misread that last comment; I thought VSCode was not up-to-date. I guess there's been a regression, but I think this is due to the way in which we handle < next to an identifier. If you put spacing around it, does the problem go away?

[aeschli]

Yes, with a space in front of the < things look fine.

[zhengbli]

@aeschli What if you have a space before your < sign? There is a known issue that the current grammar cannot differenciate the casting angel bracket and the less-than sign.

[aeschli]

@zhengbli Space in front of the < solves the issue. You can also see this in the 3rd screenshot

[anubmat]

Duplicate #11