Compiler panics when disk is full

[DemiMarie]

When compiling my project, the disk filled up and I got:

thread 'rustc' panicked at 'assertion failed: pos.get() <= self.position()', compiler/rustc_metadata/src/rmeta/encoder.rs:447:9

I’m assuming this is a compiler bug, if only because the error message is not helpful. I haven’t included an example because I don’t think the specific code being compiled matters here.

[leikang123]

The error message you provided suggests that a panic occurred in the Rust compiler (rustc) while executing the code in the encoder.rs file of the rustc_metadata crate. Specifically, the panic occurred at line 447 of the encoder.rs file and it is triggered by an assertion failure.
Assertions are used in Rust code to check certain conditions that are expected to be true at runtime. When an assertion fails, it means that the condition being checked is not satisfied, and the program panics to indicate this unexpected behavior.
In this case, the assertion failure is related to the position of a value being encoded in the metadata encoder. The position is expected to be within a certain range, but the assertion is indicating that it exceeds that range.

To resolve this issue, you can take the following steps:

1. Update your Rust compiler and dependencies: Make sure you are using the latest stable version of Rust and update your project's dependencies to their latest compatible versions. This can be done by running cargo update in your project directory.
2. Review and modify your code: Examine the code in your project that uses the rustc_metadata crate. Look for any operations or manipulations related to encoding metadata and ensure that the positions being used are valid and within the expected range.
3. Debug the issue: If you are unable to identify the cause of the assertion failure, you can try to debug the issue by adding print statements or using a debugger to inspect the state of your program at the time of the panic. This can help you pinpoint the specific code or data causing the problem.
4. Report the issue: If you believe this is a bug in the Rust compiler or the rustc_metadata crate, you can report it to the Rust community. Provide a minimal reproducible example that demonstrates the issue and any relevant details. This will help the developers investigate and address the problem.
   Remember to always use the latest stable version of Rust and keep your dependencies up to date to benefit from bug fixes and improvements.

[ChrisDenton]

Posting a wall of AI generated text is very unhelpful here. Please refrain from doing so in the future.

[saethlin]

This ICE has been reported at least 9 times now; the issues above contain a total of 7 reports, then there's this issue and @kpreid posted about running into this on the community Discord.

I do not know why we've seen a recent uptick in reports of this ICE, but as far as I can tell the root cause is this PR (which predates all the reports): #94732, which subtly changes the API of Encoder. All writes are infallible but do not necessarily update the encoder position and thus any assertion which is based on inspecting the encoder position will explode if an encoder encounters an IO error.

It looks to me like this tripping hazard wasn't noticed at the time, which is hardly surprising considering that this is along an error path and all the reports we have will result in unsuccessful compilation even if the assertion isn't tripped.

I am going to try to make this not ICE anymore. The current implementation of FileEncoder has a reimplementation of BufWriter woven together with the delayed error handling; in its current state I have little confidence in my ability to review a fix that just adds updates to the encoder position so I'm going to try to untangle the logic first.