-Z unpretty=expanded does not emit anything when abort happens during lowering

[Centril]

For example, say I have:

// compile-flags: -Z unpretty=expanded

fn main() {
    if true && let 0 = 1 {}
}

and then I have some abort_if_errors in HIR lowering that this will trigger.
This causes an error and no prettied output.

Meanwhile, I expect compilation to stop after dumping the prettied output.

cc @Zoxc @oli-obk

[V1shvesh]

Hey @Centril! Can I pick up this issue?

[Centril]

@V1shvesh sure, go for it. :)

(I have personally not investigated how or where to fix it so you'll need to do some digging.)

[V1shvesh]

Will do my best!

[Enselic]

What is a good way to trigger

abort_if_errors in HIR lowering

? The example code aborts compilation AND prints the expanded code:

$ rustc +nightly -Z unpretty=expanded ~/src/bin/src/main.rs
error[E0658]: `let` expressions in this position are unstable
 --> /home/martin/src/bin/src/main.rs:4:16
  |
4 |     if true && let 0 = 1 {}
  |                ^^^^^^^^^
  |
  = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
  = help: add `#![feature(let_chains)]` to the crate attributes to enable

#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
// compile-flags: -Z unpretty=expanded

fn main() { if true && let 0 = 1 {} }
error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
$ rustc +nightly --version
rustc 1.73.0-nightly (a6f8aa5a0 2023-08-11)

Does this mean the behavior is now as desired, and we only need to add a regression test to close this issue?

[oli-obk]

I think without a reproduction, we can close this issue and see if it gets reported again with a new repro