Type parameters don't get a highlight

[falsefalse]

Sublime Text build number

4143

Example Code

export const pickStub = <
  O = any,
  K extends keyof O = keyof O,
  TAwaitedReturn = Awaited<OverloadedReturnType<O[K]>>
>(
  key: K,
  object: O
) =>
  object[key] as SinonStub<
    any[],
    TAwaitedReturn extends Array<infer I>
      ? Promise<Partial<I>[]>
      : Promise<Partial<TAwaitedReturn>>
  >

JS Custom Preferences

{
  "defaults": {
    "eslint_directives": true
  }
}

Configuration name

JS Custom - TypeScript

Description

Lines 195, 196 and 197 don't get any highlighting 😿

[Thom1729]

Looks like the problem a) exists upstream and b) will be tricky (because the syntax here is undocumented). I'll take a look over the next couple of days.

[Thom1729]

Minimal example, BTW:

const f = <
  T, U = A < B >
> ( a ) => null;

[falsefalse]

I’d appreciate a pointer to the place where it’s supposed to happen upstream, if you know, would love to take a look as well. Very nice plug-in you got, least I could do is try to help 🙇🏻‍♂️

[Thom1729]

Well, I just checked it in the core TypeScript package, and the issue occurs there too. Weirdly, it seems to highlight nondeterministically if you remove/re-add U = A < B >. However, looking at TypeScript.sublime-syntax, I think there is an underlying bug there, so even though the glitchiness might technically be an engine bug I suspect that when the syntax is fixed everything will work fine.

As it happens, I also maintain the upstream package, so that's not an obstacle.

What is an obstacle is the fact that arrow function type parameters are just about the worst part of TypeScript syntax. Depending on the situation, they overlap with ordinary expressions using the less-than operator, old-style type assertions, and JSX tags. You can easily come up with examples that would be formally ambiguous under a reasonable grammar. However, TypeScript has no formal grammar; it's implementation-defined, like Perl, and its behavior in these cases is completely undocumented, so I have to reverse-engineer it, either using AST Explorer or by tracing through Microsoft's parser source code.

The good news is that it seems to work in the core TSX syntax for reasons I haven't yet explored. So if you need a workaround in the mean time try enabling the JSX configuration option.

[falsefalse]

Thanks for the thorough explanation!

jsx: true worked indeed

[Thom1729]

Glad the workaround works for you! Reopening the issue because I still need to fix it upstream and I'm too lazy to create another issue there.

[Thom1729]

Fixed in v4.3.0.