Hashing messages to improve performance on matching

[eddyw]

Hi 👋

I've been playing a bit with the code and it think we can do better on how errors (diagnostics) are matched. Right now as is, it iterates over the whole list of tsErrorMessages to find which ones matches the regular expressions and it's pretty expensive.

So an idea,
Having this diagnostics as input:

Argument of type 'X[] | null' is not assignable to parameter of type 'T[] | null'.
  Type 'X[]' is not assignable to type 'T[]'.
    Type 'X' is not assignable to type 'T'.
      'X' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'X'.

Knowing that types are always represented in single quotes 'T' we can remove all type information from the diagnostics. For example:

const UserInputDiagnostics = `
Argument of type 'X[] | null' is not assignable to parameter of type 'T[] | null'.
  Type 'X[]' is not assignable to type 'T[]'.
    Type 'X' is not assignable to type 'T'.
      'X' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'X'.
`;

const MatchDoubleQuotes = /"([^"]*)"/g;
const MatchSingleQuotes = /'([^']*)'/g;

console.log(
  UserInputDiagnostics.replace(/\\"/g, "") // Remove escaped double quotes first if any
    .replace(MatchDoubleQuotes, "?")       // Remove double quoted types
    .replace(MatchSingleQuotes, `'?'`)     // Remove type information in single quotes
);

This turns the input into this:

Argument of type '?' is not assignable to parameter of type '?'.
  Type '?' is not assignable to type '?'.
    Type '?' is not assignable to type '?'.
      '?' is assignable to the constraint of type '?', but '?' could be instantiated with a different subtype of constraint '?'.

TS diagnostic chains are flatten into a single message where diagnostic messages are joined with a new line separator. This means it's easy to split them all by \n and trim the leading spaces:

const Lookup = [
  "Argument of type '?' is not assignable to parameter of type '?'.",
  "Type '?' is not assignable to type '?'.",
  "Type '?' is not assignable to type '?'.",
  "'?' is assignable to the constraint of type '?', but '?' could be instantiated with a different subtype of constraint '?'.",
]

So why do this at all?
We can use the same logic above to clean args information from the tsErrorMessage keys. For instance:

Argument of type '{0}' is not assignable to parameter of type '{1}'.

Turns into:

Argument of type '?' is not assignable to parameter of type '?'.

So finding a match is O(1). For instance, this could turn into something like this:

const MatchedDiagnostics = Lookup.map(diagnosticKey => {
  return tsDiagnosticRecord[diagnosticKey]; // e.g: ErrorInfoWithoutImprovedError
});

In this particular case, it'll only iterate over 4 elements instead of +1000 diagnostics.
It's a simple way to generate a hash. Going further they could be converted to sha256 hashes which would probably reduce the memory footprint since keys will be smaller than the avg diagnostic message.

Of course, this doesn't cover all cases. There are a few exceptions such as this one:

Generic type 'T' requires between 1 and 2 type arguments.

...but to be fair, the current code in the repo doesn't cover this case either haha

I'll be glad to contribute. I'm just opening the discussion before opening a random PR with radical changes 😅

[mattpocock]

Just saw this! Very open to this change. The current algo is basically indefensible in terms of speed or quality. If you can make a PR to improve it I'd absolutely love it.

[eddyw]

@mattpocock open this RFC PR #37 to talk about it. Hope it makes sense 😅