To report a compile bug or not?

1

I have a bit of a dilemma.

Prompted by a discussion in another thread just now I was playing around with writing some Rust that did not use std or core. I ended up with rustc crashing out with a stack dump and some messages. Including:

error: the compiler unexpectedly panicked. This is a bug
note: please attach the file at `...../rustc-ice-2026-08-20T11_40_13-22125.txt` to your bug report

Normally I would be looking where to send a bug report at this point.

But here is my dilemma: My code example was not written by me. It is the result of cycles of prompting my AI friend, seeing compile errors and prompting again. In the current atmosphere I see many projects are allergic to AI generated input from random users. Which I can understand.

So, should I report it or not?

Here is the code:

#![feature(no_core, lang_items, intrinsics, rustc_attrs)]
#![no_core]
#![no_main]

// --- Minimal Modern Layout Primitives ---
#[lang = "pointee_sized"]
pub trait PointeeSized {}

#[lang = "meta_sized"]
pub trait MetaSized: PointeeSized {}

#[lang = "sized"]
pub trait Sized: MetaSized {}

#[lang = "copy"]
pub trait Copy {}
impl Copy for i32 {}

// --- The Exact Internal Intrinsic ---
// 'unchecked_shl' is the concrete string rustc uses for raw bit-shifting.
#[rustc_intrinsic]
pub unsafe fn unchecked_shl(x: i32, y: i32) -> i32 {
    loop {}
}

// --- Independent Logic Function ---
#[inline(always)]
pub fn double_i32(val: i32) -> i32 {
    unsafe { unchecked_shl(val, 1) }
}

// --- Entry Point & Stubbed External Symbols ---
extern "C" {
    fn rust_begin_unwind() -> !;
}

#[no_mangle]
pub extern "C" fn _start() -> ! {
    let num: i32 = 21;
    let _result = double_i32(num);

    loop {}
}

This is how I build it:

rustc --version 
rustc 1.99.0-nightly (3d6c19bb9 2026-08-11)
rustc compiler_bug.rs
2

why are you omitting?

note: using internal features is not supported and expected to cause internal compiler errors when used incorrectly

3

Good question. No good reason. I was concentrating on the "This is bug" part and the invitation to report it and include that file.

4

it's not the AI that is the problem, but that people not understanding what they are doing is the real problem. AI is just a tool, it's powerful, but people need specific knowledge to use it to do useful things.

this is not a compiler bug.

although both use the same #![feature()] attribute to enable, internal features like intrinsics are very different from the "regular" unstable features such as allocator_api or trait_alias.

internal features are reserved for the standard library implementors, and the compiler makes strong assumptions of them.

in you example, the correct intrinsics for unchecked_shl must have this signature:

the compiler assumes an intrinsic with this name must have this signature, and yours are wrong, that's what caused the panic.

5

Ah, OK.

Then I have to report the bug that it says "This is a bug" when it is not :slight_smile:

I can accept the bug is in my code. But having a compiler crash to point that out is not a usual experience for me.

6

here's one way to look at it:

although people argue no_core has its own use cases and should be stablized, similar to no_std, but as it current stands, the only real use case of no_core is for authoring the core crate.

now imagine if core somehow triggered the same rustc panic, it would naturally be categorized as a core bug, instead of a rustc bug.

when you use no_core, you are essentially "the core".

I like how this comment puts it:

I don't think ICEs with #![no_core] are worth addressing. It's a perma-unstable feature, and lang items are effectively internal compiler code that happens to be written in a crate. We don't try to prevent ICEs in the face of modifications to the compiler itself ...

7

The point is that the "this is a bug" message absolutely is intended to mean "this is a compiler bug". The fact that it’s displayed also in the case of possibly not actually being a compiler bug is just because nobody has customized the diagnostic for that edge case, only the note is added to the same base message. It’s a (very minor) UX issue. Arguably though anyone who ignores the rather visible warnings you get when using internal features is asking for it. OTOH the internal_features lint should maybe be deny by default. And if an LLM then "helpfully" adds an allow, well, the user definitely can’t blame anyone but themselves at that point.

So, I guess, the answer for @ZiCog is "no, you shouldn’t report a bug if you don’t even understand what your code is doing, and what the boundary conditions are, because an LLM wrote it".

8

OK, I will not be reporting a bug.

However I don't agree that I should not report it because I don't fully understand what the code tries to do or because an LLM wrote it. To my mind it's code, albeit faulty, historically we expect compilers to exit cleanly with an error rather than crash out with a stack dump. Same as we expect for any other program with input it does not understand. After all, I'm using a nightly compiler, it's not unheard of that there may have been some regression introduced recently that causes the crash.

9

in this case I'd just say that your fuzzer was slightly more expensive than usual :smiley:

10

Ha!

Actually in this case "My AI friend" was the AI mode of Google search. It's amazing how much code it will write for free. Sorry for wasting peoples time with this here. At least I learned a few Rust things.

11

still expensive for them and the enviromnent

[/ot]

12

it's totally reasonable to report a compiler crash. I don't think people here are saying you should not report a bug if the code is produced by LLM or what. they are just pointing out this case is a false alert.

side note: my previous comment on people using LLM without understanding what they are doing is in response to the "in today's atomosphere" part, not directed to this specific case. these LLM produced reports are in very large quantites but are generally lower quality, many open source projects are overwhelmed because they don't have the bandwidth to process this much data.

now back to compiler bug reports. I don't think it would really be a big deal if you open a ticket. the most likely outcome is someone from the compiler team sees it, and deems it to be a non-bug, then closes the issue, probably with a short rely explaining internal features are not supported, and/or a link to previous discussions.

I would say it's very considerate of you to ask on the forum before reporting it, so people less busy than the compiler team can take a look at it.

sure, an elegant shutdown would be much better ux and less confusing.

on the other hand, historically, no other compilers were designed to be this plugable like rustc, nor do they expose this level of internal knobs to library authors. most other compilers don't have the concept of lang items in rustc. instead, they are either hardcoded in the compiler and injected to the user code, or they invent adhoc solutions for individual features.

the design of rustc is truly unique in many ways.

and because these internal attributes are contracts between the compiler and the standard library (hence, "internal"), it's an acceptable trade off to be less defensive in these area and just assert!() or .unwrap() if the contracts can only be violated if the libcore has a bug.

that's a fair point.

this is more of a ux problem of the way it reports errors. no_core code are not "normal" compiler inputs, but they are input nevertheless. I suppose the compile can provide a different panic hooks when dealing with no_core code, so an failed assert or unwrap does not show the confusing message "this is a bug, please attach ... to the report".

I think we should either document in more detail about the difference between "internal" features and "unstable" features, or maybe we reserve the #![feature()] attribute for unstable features only, and move internal features to a different directive, something like #![internal_feature()] or #![rustc_feature()]? would that be less confusing or more confusing?

13

Out of curiosity, did you ask your AI friend whether you should file a bug report?

If you use AI to write code, I think it is definitely worth using a coding agent, because it is so much easier, more robust and more efficient than copy-pasting code from a chat. A coding agent can look at your project and besides coding can also build and test it, and commit and push to GitHub for you. Claude is the most popular, but I found Codex works well for me and I can use it as part of my ChatGPT subscription.

14

Nope. Not even close. Triggering :ice: for most production compilers is not that hard with incorrect code. GCC, Clang, ICC, you name them. What? :ice: for incorrect code? We'll take a look, maybe, ask us 10 years later…

Yes, but no. Only when code is actually correct priority is high enough to warrant immediate investigation.

Precisely. I remember how my friends in Intel were asked to generate test cases for the Intel Fortran compiler. Simple fuzzer generated enough test cases that their team more-or-less paralized work of the compiler guys. There was a high-level buzz about it and they were asked not to use fuzzers, anymore.

If code is actually correct or when code is incorrect but comes from some high-profile project attentions is high. If code is not actually correct, nope. Compiler developers just don't have enough free hands to handle all of these, it's as simple as that…

15

Per the LLM policy, reporting bugs found via LLMs is allowed as long as you verify it manually. In this case, though, as others said, this is not a bug but an abuse of internal-only features, and there is a warning for that.

Making the LLM submit an issue for you, like someone here has suggested, is absolutely forbidden and will easily cause you to be banned from the Rust project.

16

I have been using the Warp terminal for some experiments with AI coding since last year. The other day I started trying out Codex. Today all the buzz was around the new Deepseek Harness so I just now got that installed and chatting.

Deepseek seems to be very cheap if used during off peak hours, it's been writing Rust for me for four hours and cost 12 Cents for 7 million tokens. The code looks pretty nice.

Oh... No I did not ask my AI friend that.

17

When I do fuzz testing, the input is random generated yet discovered input sequence causing crash is a bug report for me, especially if I can convert it into reproducible test. AI cannot be worse than random, unless to reject on ethical grounds. I am surprised to read that crashing on invalid input rather than reporting error is common and unimportant for a compiler.

18

Hmm... In 30 years of programming I have only managed to crash a compiler a couple of times. And I have used many languages and compilers. I also generate a lot of bad input for them :slight_smile:

19

AI is significantly worse (or better, depends on what we are measuring) than random. That's why he see increase in CVE numbers. Random fuzzing existed for years, it couldn't produce as many vulnerabilities as AI could. Yet even random often produces more error reports than most compiler developers may accept.

It's an open secret. Few compiler developers would reject a bug report that crashes a compiler. Even fewer would investigate it if source of error is not obvious on the first glance and code that triggers the problem is invalid.

Compiler developers are severely overloaded, they don't even have time to fix bugs that come from programs that are valid, they certainly don't have badwidth to handle fuzzer-based reports.

20

You can consider using internal features to be overriding part of the compiler. With that POV, it's not surprising or unexpected that a bug in your code can result in an "internal" compiler error.

I'm not on any teams, but here's a link to the policy.

ICEs or confusing diagnostics when using internal-only features like intrinsics or lang items incorrectly are not considered rustc bugs.

The policy is such that even robustness and diagnostic improvements are supposed to be rejected if they add complexity to the compiler.