Stack overflow in type instantiation with recursive function and generic type params

[wadjoh]

Description

A project at my job causes a stack overflow with tsgo, but compiles with tsc.
Tracked it down to a recursive object transformation function that changes the casing of the object's string properties.
It uses the CamelCase type from type-fest.

I have a code example that's as minimal as I could figure out how to make it: https://github.com/wadjoh/tsgo-crash-repro.

EDIT: The crashing seems to have started happening with type-fest version 4.38.0 and starts working again with version 5.0.0.
Change in 4.38.0 that started causing the crashing: sindresorhus/type-fest#1081
Diff of 4.41.0 and 5.0.0 (not sure which of the changes stops the crashing): sindresorhus/type-fest@v4.41.0...v5.0.0

Stack trace

The full stack trace is large so I'll paste the first part of it here and paste a link to a gist with the full stack trace.

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0x44423d7f0570 stack=[0x44423d7f0000, 0x44425d7f0000]
fatal error: stack overflow

runtime stack:
runtime.throw({0x104c6d915?, 0x1045baed4?})
        runtime/panic.go:1229 +0x38 fp=0x16b8768e0 sp=0x16b8768b0 pc=0x1046015d8
runtime.newstack()
        runtime/stack.go:1178 +0x498 fp=0x16b876a10 sp=0x16b8768e0 pc=0x1045e8648
runtime.morestack()
        runtime/asm_arm64.s:507 +0x70 fp=0x16b876a10 sp=0x16b876a10 pc=0x104607070

Full stack trace: https://gist.github.com/wadjoh/82adc287ab15357812c8e2da247163c3

Steps to reproduce

1. Clone https://github.com/wadjoh/tsgo-crash-repro
2. Run pnpm i
3. Run pnpm check:tsgo
4. Observe stack overflow panic

You can also run pnpm check:tsc and see that it successfully compiles.

Example code that causes the crash

import { CamelCase } from "type-fest";

const transform = <TResult>(iteratee: any): TResult => undefined as any;
const camelize = <T extends object>(): CamelCase<T> => transform(camelize);

[apendua]

A fun fact, this crash does not seem to occur with the latest version of type-fest (i.e. ^5.0.0), but I was able to confirm that it breaks for ^4.0.0.

[wadjoh]

Oh that's a really good callout! Didn't occur to me try out different versions of type-fest.
Now I'm able to narrow down the issue a lot more.

The stack overflow starts with type-fest 4.38.0. Specifically due to this change: sindresorhus/type-fest#1081

It stops crashing with type-fest at version 5.0.0. Not sure what change in type-fest causes it to start working again, but the whole diff between 4.41.0 and 5.0.0 is here: sindresorhus/type-fest@v4.41.0...v5.0.0

I'll add this info to the issue description.

[jakebailey]

Also try TS 6.0 with --stableTypeOrdering.

[wadjoh]

With some more testing, I was able to get it down to a 3-line example with type-fest@4.38.0 🎉
I've updated the initial description with it.

Also try TS 6.0 with --stableTypeOrdering.

I updated TypeScript in the repo to 6.0.0-beta and added --stableTypeOrdering to the check:tsc pnpm command and it still successfully compiles.

[jakebailey]

#2940 is sort of interesting, because it implies that we are running out of stack where we didn't before. That would very much surprise me, but maybe we stack allocate so much for perf that JS did not do (and instead was a nursery object or something)...

[ahejlsberg]

This appears to be caused by #1795, which didn't completely port microsoft/TypeScript#61668. I've initiated #2979 to compare the PRs and complete the port. I can confirm that the problem is fixed by #2979.

[ahejlsberg]

Fixed by #2979. Closing.