[JavaScript] TypeScript cast throws off further highlighting

[rchl]

What happened?

This probably can be simplified quite a bit.

Things already seem wrongly colored on the two method, after the cast.

const x = {
    one() {
        return foo as number < 3;
    },
    two() {
        this.update({
            bar: true,
        });
    },
}

[Thom1729]

Ugh. It's surely parsing this as foo as (number < 3; …, not (foo as number) < 3;. I'm playing around with it in AST Explorer and apparently TypeScript parses number<3 differently from Foo<3, which is annoying (and, of course, totally undocumented). I guess I need to special-case the builtin types so that they don't try to consume generic parameters.

[rchl]

Not sure if I understand how you intend to fix it but note that instead of number one could use Foo where Foo is type Foo = number.

[Thom1729]

I don't think x as Foo < 3; is valid. In AST Explorer, it parses all of Foo < 3 as a type reference (which is invalid because it's missing the closing >). So I think that it will always treat the < as the beginning of type arguments after a general identifier, and never after a special identifier like number.

The solution I'm trying is removing the type argument handling from ts-type-expression-end and putting it in ts-type-basic instead. That passes all of the current tests, and fixes x as number < 3. I'm currently digging around for other corner cases to look at.

[Thom1729]

N.B. While I think that x as Foo < 3; is invalid, it does break rather ungracefully, and this is probably worth improving as well. Probably by telling the type contexts to bail if they see a semicolon, or somesuch.

[rchl]

I don't think x as Foo < 3; is valid.

you're right

[Thom1729]

Should be fixed in the linked PR.

[rchl]

Probably by telling the type contexts to bail if they see a semicolon, or somesuch.

Note that the community likes to omit semicolons for the sake of cleaner code. So that... :)

[Thom1729]

Eh, only so much we can do in such cases. For one thing, there's no way to detect EOF, so it's almost impossible to handle some otherwise-ambiguous constructs right before EOF.

Here, it's invalid syntax either way, so highlighting is on a best-effort basis. I didn't bother addressing that case in the linked PR because the solution for the valid case turned out to be simple. I did note that VSCode's fails in the same way in the invalid case, for what that's worth.