crate fails to compile release build (v1.65+) with rustc crashing

[d00z3l]

The crate linked below no longer compiles on version 1.65 (and 1.66). On version 1.64 and prior it successfully compiles. The issue only applies to release builds. During compilation the memory for rustc gradually grows until it fails to allocate memory. In my case around 40+GB of memory being used by rustc.

Code

https://github.com/d00z3l/python

I expected to see this happen: release build compile

Instead, this happened: rustc crashes

Version it worked on

It most recently worked on:

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-pc-windows-msvc
release: 1.64.0
LLVM version: 14.0.6

Version with regression

rustc 1.66.0 (69f9c33d7 2022-12-12)
binary: rustc
commit-hash: 69f9c33d71c871fc16ac445211281c6e7a340943
commit-date: 2022-12-12
host: x86_64-pc-windows-msvc
release: 1.66.0
LLVM version: 15.0.2

Backtrace

rustc crashes, with RUST_BACKTRACE enabled the cmd process also crashes so I can't get the backtrace output

[Noratrieb]

I can reproduce this on 1.66 but it's been fixed on the latest nightly where I can't reproduce it anymore.
After a quick bisection and some searching I found that this was fixed by #105119

[d00z3l]

Thanks for looking in to it. Confirmed that it is compiling on recent nightly:

rustc 1.68.0-nightly (c7572670a 2023-01-03)
binary: rustc
commit-hash: c7572670a1302f5c7e245d069200e22da9df0316
commit-date: 2023-01-03
host: x86_64-pc-windows-msvc
release: 1.68.0-nightly
LLVM version: 15.0.6

Will this fix will be in the next stable release? Also is there a config option to disable top-down inlining?

[Noratrieb]

If you need to use stable you can disable MIR inlining with RUSTFLAGS=-Zinline-mir=no. Since this is an unstable flag, you will have to use the RUSTC_BOOTSTRAP=1 flag. This is a terrible hack that you should usually never do in production but in this case it will be fine until the next version.
You could also use beta if you can, it should be fixed there as well.

[d00z3l]

Ok, thanks

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[pnkfelix]

Discussed in P-high review

This was indeed fixed by PR #105119 and thus was fixed in Rust stable 1.67.

Normally the next step would be a regression test, but given that this was a memory exhaustion issue and PR #105119 had its own regression tests, I don't think we need separate tests for this issue.

Closing as fixed.