Stack overflow in TS 4.5.3 and nightly

[DanielRosenwasser]

I'm running into a similar issue. When I run tsc on our node project, I get RangeError: Maximum call stack size exceeded.

Everything was working fine - this just happens when I attempt to upgrade to typescript 4.5.3. It works fine in typescript 4.2.3.

FWIW, recursive types should definitely be allowed. They're a standard part of any programming language (more generally, Context Free Grammars) and it's very common to do this (e.g. with datastructures like trees, or compilers, etc.).

e.g. it's 100% valid to have:

type Tree<T> = { data: T; children: Tree<T>[] } 

Unfortunately the stacktrace I get doesn't give me any indication of which type is causing the issue:

/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:94444
                throw e;
                ^

RangeError: Maximum call stack size exceeded
    at getRelationKey (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:54317:32)
    at recursiveTypeRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52985:26)
    at isRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52645:30)
    at typeRelatedToSomeType (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52869:35)
    at structuredTypeRelatedToWorker (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:53099:32)
    at structuredTypeRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:53084:30)
    at isRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52642:30)
    at checkTypeRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52314:26)
    at isTypeRelatedTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:52276:24)
    at isTypeAssignableTo (/Users/cbattycapps/{REDACTED}/node_modules/typescript/lib/tsc.js:51558:20)

Originally posted by @charlescapps in #45576 (comment)

[DanielRosenwasser]

If you open up tsc.js and add the following line to the top of checkTypeRelatedTo

console.log(`Checking if ${typeToString(source)} is related to ${typeToString(target)}`);

that might give you an indication of where things are going off the rails, and will help us come up with a repro and possible fix.

[sloonz]

Simplest repro I could do :

import {Model} from "objection";

export class Organization extends Model {
  id!: number;
  users?: User[];

  static get relationMappings() {
    return {
      users: {relation: Model.HasManyRelation, modelClass: User, join: {from: "organizations.id", to: "users.organizationId"}},
    };
  }
}

export class User extends Model {
  id!: number;
  organizationId!: number;
  organization?: Organization;

  static get relationMappings() {
    return {
      organization: {relation: Model.BelongsToOneRelation, modelClass: Organization, join: {from: "users.organizationId", to: "organizations.id"}},
    };
  }
}

package.json :

{"name":"tscbug","dependencies":{"objection":"^3.0.0","typescript":"^4.5.3"}}

tsconfig.json (nothing fancy, generated by tsc --init) :

{
  "compilerOptions": {
    "target": "es2016",                                  /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
    "module": "commonjs",                                /* Specify what module code is generated. */
    "esModuleInterop": true,                             /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility. */
    "forceConsistentCasingInFileNames": true,            /* Ensure that casing is correct in imports. */
    "strict": true,                                      /* Enable all strict type-checking options. */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  }
}

[DanielRosenwasser]

Thank you for the repro! That'll help us expedite a fix, though a lot of people are going to be out for a bit, so please be patient.

[ahejlsberg]

I bisected using the repro. This appears to be yet another casualty of #30639. That said, we should of course never overflow the stack. I can fix that, but when I do we now report an Excessive stack depth comparing types 'UpsertGraphMethod<?>' and 'UpsertGraphMethod<?>' error. Effectively, attempting to compute variance for the UpsertGraphMethod type ends up spiraling forever (because with #30639 we keep exploring assignability to a conditional type on the target side).

[ahejlsberg]

@weswigham Any ideas here?

[ahejlsberg]

Actually, with a couple of minor fixes (without which the variance computation for UpsertGraphMethod runs amok) the repro now compiles as it did with 4.2. I will put up a PR.