TypeScript colorizer confused by comments after colon in class member function signature with Generic return type

🔎 Search Terms

color comment white Promise async function type declaration

🕗 Version & Regression Information

• I was unable to test this on prior versions because no idea when this started

⏯ Playground Link

https://vscode.dev

💻 Code

import os from 'os';

type Test<T> = T;

export class test {
  fine(): Test<void> {
    const test = 0;
  }
  ok(): /**/ Test<void> {
    const test = 0;
  }
  bad(): // any comment with a new line breaks colorizer for a function
  Test<void> {
    const test = 0;
    os.hostname();
    true ? false : undefined;
    throw new Error('');
    return;
  }
  fixed() // Not broken this way. Compare colorization with the bad function.
  : Test<void> {
    const test = 0;
    os.hostname();
    true ? false : undefined;
    throw new Error('');
    return;
  }
  alsoBad(): /* can be a /* comment too, but formatters usually remove the new line unless it is really long */
  Test<void> { // all but { colors are different
    const test = 0; // const is white
    os.hostname(); // all alpha is white
    true ? false : !!undefined; // true and false are different
    throw new Error(''); // throw is different, but not new or Error
    return; // return is different
  }
}

function ok(): // not broken outside of class
Test<void> {
  const test = 0;
}

🙁 Actual behavior

In the class functions that have comments after the : in the signature but before the actual Generic type, I noticed many differences from normal:

• Type coloring is different
• const is white
• global variables are white
• true and false are different in ternary
• throw is different, but not new or Error
• return is different

🙂 Expected behavior

Consistent colorizing, no matter the comments

Additional information about the issue

Does not reproduce on GitHub or playground's colorizer. Reproduces quickly and easily on vscode.dev.

I wasn't sure where to post this issue. It seem like a very TypeSript specific issue, but maybe this should be a VS Code bug...