Building some applications causes whole system to crash (out of memory)

[WeebNetsu]

Description

Note: Original Issue

When trying to build Lesson 50 using nimble build, it will quickly use up all my systems RAM and force me to reboot to get it to respond again. This some sort of leak or maybe unhandled memory usage?

I recorded a video to show what happens, I cancelled the execution before my system crashed of course
https://github.com/user-attachments/assets/368a64ba-bc5e-4269-96f5-23c0ef605944

This seems to be a new issue, since I was previously able to build this without issue - have also been replicated by Patitotective

Nim Version

Nim Compiler Version 2.2.0 [Linux: amd64]
Compiled at 2024-10-02
Copyright (c) 2006-2024 by Andreas Rumpf

git hash: 78983f1
active boot switches: -d:release

Current Output

It seems to produce this bit of info before taking my system for a ride:

Verifying dependencies for [email protected]
   Building project/project using c backend
/home/netsu/.nimble/pkgs2/async_http_request-0.1.4-944652f72180b0daac91cd897a466e3a0f7c0625/async_http_request.nim(157, 34) template/generic instantiation of `request` from here
/home/netsu/.choosenim/toolchains/nim-2.2.0/lib/pure/httpclient.nim(1154, 14) Warning: Deprecated since v1.5; use HttpMethod enum instead; string parameter httpMethod is deprecated [User]

Crashes my system before much else is displayed

### Expected Output

```text
Application should build an executable without crashing the system

Known Workarounds

No response

Additional Information

In case important:
OS: OS: EndeavourOS (Arch Linux)
CPU: AMD Ryzen 7 5700X (16) @ 3.400GHz
RAM: 16GB
nimble v0.16.1 compiled at 2024-10-02 02:00:57

[metagn]

This seems to be an infinite loop in the variant.getTypeId macro here in the proc mangledNameAux (not the obvious while true loop), which the compiler does not catch somehow. However this is the getTypeId macro from the 0.2.13 version of variant, not the current 0.3.1 version, which is installed because nimx requires a version below 0.3. The current implementation of getTypeId seems immune to infinite recursions.

Something to note is that the line in nimx's package file which restricts the variant version was added in 2016 but the 0.3 version is only from August 2023 and was updated as recently as August of this year, so it's possible that the new version of variant not being used isn't intentional. So changing nimx to allow variant >= 0.3 is an option. Edit: Opened yglukhov/nimx#528

As for the infinite loop itself, it happens because t is equal to getType(t), with the value tuple[proc[void, string], proc[string]]. This is the case in 2.0.8 but not 2.0.2 (did not test versions in between). Very likely the culprit is #22655, if the node is a tuple[...] node then it should not have type tyGenericInst.

There is also the issue that the VM doesn't catch the infinite loop, idk what the problem is there.

[Araq]

There is also the issue that the VM doesn't catch the infinite loop, idk what the problem is there.

Maybe it would catch it but it runs out of memory first.

[metagn]

Since yglukhov/nimx#528 was merged, nimx now uses the newest version of variant which doesn't have this problem, so the project above should build now.

#24512 would also stop the infinite memory use by detecting the infinite recursion early.

But the issue with getType is not fixed, all of #24509, #24510, #24511 break at least one package, I haven't looked into how exactly it is breaking but I'm not sure if those PRs are reasonable enough to change packages. An option is reverting #22655 but this reopens #22639 which was already fixed and reverted before.