[ICE]: Multiple hangs with specific compiler options

[wxie7]

Code

EDIT: dropped not required flags

timeout 30 /path/to/rustc --crate-type staticlib -C link-dead-code -C debuginfo=2 -C opt-level=3 -Z mir-opt-level=3 file.rs

Affected release channels

• Previous Stable
• Current Stable
• Current Beta
• Current Nightly

Rust Version

$ rustc -Vv
rustc 1.84.0-nightly (b8c8287 2024-11-03)
binary: rustc
commit-hash: b8c8287
commit-date: 2024-11-03
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3

Current error output

No response

Backtrace

no backtrace

Anything else?

The attached files contain multiple source codes that cause the compiler to hang.
hangs.zip

[jieyouxu]

-Z unsound-mir-opts=yes

Well...

[jieyouxu]

@wxie7 does the hang repro without -Z unsound-mir-opts=yes, because unsound mir-opts are, like the flag name suggests, unsound.

Marking as S-needs-repro for a repro that uh repros without unsound mir-opts.

[jieyouxu]

And even better, does the hang repro with fewer flags?

[wxie7]

@jieyouxu Even after removing -Z unsound-mir-opts=yes -Z polonius=next -Z polymorphize=yes flags, the compiler still hangs.

[jieyouxu]

We'll need to cleanup the code examples produced via mutation testing (run through rustfmt, trim down irrelevant errors, etc.)

[jieyouxu]

And also, to clarify @wxie7 do they produce Internal Compiler Errors (ICE) which is usually associated with an ICE message, or do they just hang (i.e. don't terminate)?

[jieyouxu]

Thank you for the report, it would be very helpful next time if you indicated that these hangs are found via some kind of fuzzing, see the fuzzing guidelines in the dev-guide.

[Noratrieb]

@wxie7 -Zunsound-mir-opts mean that the opt is known to be broken, so testing that will not really lead to interesting results, it doesn't matter if there are gaps in the test suite for something we know is wrong anyways. we're not exactly very keen on preserving this wrong behavior :)

[jieyouxu]

(Also triage remark: we'll need to split this issue into multiple actionable individual issues, as it stands there's too many code examples that might not hang with the same flags and causes)

[wxie7]

And also, to clarify @wxie7 do they produce Internal Compiler Errors (ICE) which is usually associated with an ICE message, or do they just hang (i.e. don't terminate)?

just hang

[wxie7]

In fact, some examples not included in the attachments have triggered ICE. Should I submit each example as a separate issue?

[jieyouxu]

Triage: @wxie7 I took a brief look at the example code snippets, they definitely need their individual bug reports because they are widely different:

E.g.:

• As you mentioned, some of them hang, some of them ICE, they are of different nature.
• Some of them have very early/broken/incomplete features like #[feature(generic_associated_types_extended)]. They definitely need their own bug reports because some of them may already be known (as bugs or known incomplete).
• Some of them use internal features like #[feature(rustc_attrs)] or #[rustc_coinductive] which are known to be internal features, and if they are misused it's not necessarily a bug cf. Policy for ICEs on incorrect usage of internal-only features compiler-team#620.
• Even for the same compiler flags, their cause might be entirely different.

Yes, please kindly submit individual bug reports for them and consider what I mentioned above, thank you! If you do file separate issues, it will help to mention that they are synthesized from fuzzing.

[workingjubilee]

@wxie7 Yes, please follow the rustc dev guide instructions:

Please do:

Ensure the bug is still present on the latest nightly rustc
Include a reasonably minimal, standalone example along with any bug report
Include all of the information requested in the bug report template
Search for existing reports with the same message and query stack
Format the test case with rustfmt, if it maintains the bug
Indicate that the bug was found by fuzzing

Please don't:

Don't report lots of bugs that use internal features, including but not limited to custom_mir, lang_items, no_core, and rustc_attrs.
Don't seed your fuzzer with inputs that are known to crash rustc (details below).

[jieyouxu]

To summarize what we have above, please do file individual issues. I'm closing this particular issue as it's too much of a kitchen sink and is not very actionable. Thanks!

[wxie7]

@jieyouxu Is it reasonable to add -Z polonius=next -Z polymorphize=yes during testing?

[jieyouxu]

Is it reasonable to add -Z polonius=next -Z polymorphize=yes during testing?

I asked in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.60-Zpolymorphize.60.2F.60-Zpolonius.60.20when.20fuzzing.3F because I'm not too sure about it either. Before that gets answered, I would avoid adding these specific unstable flags (-Z polonius=next -Z polymorphize=yes) during fuzzing for now.

[jieyouxu]

@wxie7 Based on discussions in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/.60-Zpolymorphize.60.2F.60-Zpolonius.60.20when.20fuzzing.3F, let's avoid fuzzing with those specific flags for now.