Crash when formatting complex file

[mobiusklein]

cargo fmt and cargo rustfmt crash when processing https://github.com/mobiusklein/mzdata/blob/34b2d6feb3201140991fa66b53960ab8141c7ed7/src/io/infer_format.rs. See below for traceback.

Toolchain: stable-x86_64-pc-windows-msvc
Version: rustc 1.76.0 (07dca489a 2024-02-04)
Platform: Windows 10

Supposition

This file specifically started to crash the formatter when I added a few large, complex generic algebraic types, Source and Sink, and another generic-heavy trait to consume them, MassSpectrometryReadWriteProcess.

Traceback:

Details

hread 'main' panicked at src\tools\rustfmt\src\items.rs:547:10:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:     0x7fffed4822c2 - ::fmt::h7851e041f2b8bcc2
   1:     0x7fffed4b4cdd - core::fmt::write::h1642dfca37b49735
   2:     0x7fffed478ca1 - ::fmt::h7801514a6fc13a4a
   3:     0x7fffed4820ea - std::sys_common::backtrace::lock::h8caaa69a6cc2258b
   4:     0x7fffed485529 - std::panicking::default_hook::h67f6260a0bf37eca
   5:     0x7fffed4851e5 - std::panicking::default_hook::h67f6260a0bf37eca
   6:     0x7ffff1d0fb03 - ::write_fmt
   7:     0x7fffed485b43 - std::panicking::rust_panic_with_hook::h870983d929e74e12
   8:     0x7fffed4859ab - ::take_box::h971268ed26284d4c
   9:     0x7fffed482bc9 - ::fmt::h7851e041f2b8bcc2
  10:     0x7fffed4856b2 - rust_begin_unwind
  11:     0x7fffed4da447 - core::panicking::panic_fmt::ha5dd7a91f3010b68
  12:     0x7fffed4da522 - core::panicking::panic::h61d0277f5e1a7407
  13:     0x7ff64a524bde - 
  14:     0x7ff64a51c2d6 - 
  15:     0x7ff64a52a2ea - 
  16:     0x7ff64a4992b8 - 
  17:     0x7ff64a49fa3b - 
  18:     0x7ff64a49cf53 - 
  19:     0x7ff64a497690 - 
  20:     0x7ff64a482682 - 
  21:     0x7ff64a4961af - 
  22:     0x7ff64a4806bf - 
  23:     0x7ff64a47e5c4 - 
  24:     0x7ff64a49bcb6 - 
  25:     0x7ff64a4974dc - 
  26:     0x7fffed46ae32 - std::rt::lang_start_internal::h68f55995b3e4e811
  27:     0x7ff64a4834fc - 
  28:     0x7ff64a83acbc - 
  29:     0x7ff8b1ea7344 - BaseThreadInitThunk
  30:     0x7ff8b35426b1 - RtlUserThreadStart

[ytmimi]

Thanks for the report. This feels like it's related to #5738.

Here's a smaller reproducible test case:

enum MZReaderType<
    D: DeconvolutedCentroidLike + Default + From<DeconvolutedPeak> + BuildFromArrayMap=DeconvolutedPeak
> {}

[iddm]

Any news on that matter? Kind of unusable right not for many projects of mine. I'd say it is kind of high priority, for it doesn't work in many projects of mine and those aren't necessarily "complex".

[ytmimi]

@iddm There are no updates to share at the moment. PRs are welcome!

[iddm]

Well, I understand the PRs are welcome, but there have been many commits for something else, which I doubt is more important than actually making it work. On none of the projects I have in my workspace, it works and hasn't been for a month or more. How come no one even considers this? Even the "hello world" crashes:

cargo new test-fmt
cd test-fmt
cargo fmt

Leads to

cargo fmt
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.

How come anything is more important than this?

It is not that just I need this and I am an unthankful user, this is about the project as a whole, as it doesn't even work with any project, just stopped.

rustc --version
rustc 1.78.0 (9b00956e5 2024-04-29)
cargo-fmt --version
rustfmt 1.7.0-stable (9b00956 2024-04-29)

Just in case:

RUST_BACKTRACE=1 cargo fmt
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: rust_begin_unwind
             at libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:71
   9: core::panicking::panic
             at libcore/panicking.rs:51
  10: <cargo_metadata::WorkspaceMember as serde::de::Deserialize<'de>>::deserialize
  11: <&'a mut serde_json::de::Deserializer<R> as serde::de::Deserializer<'de>>::deserialize_seq
  12: <&'a mut serde_json::de::Deserializer<R> as serde::de::Deserializer<'de>>::deserialize_struct
  13: serde_json::de::from_str
  14: cargo_metadata::metadata_deps
  15: cargo_metadata::metadata
  16: cargo_fmt::main
  17: std::rt::lang_start::{{closure}}
  18: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  19: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  20: std::rt::lang_start_internal
             at libstd/panicking.rs:458
             at libstd/panic.rs:358
             at libstd/rt.rs:58
  21: main
  22: <unknown>
  23: __libc_start_main
  24: _start

[calebcartwright]

I'm going to minimize some of these comments as they feel orthogonal to this particular issue, and are representative of issues experienced by a user (@iddm) that have been reported across multiple issues (#2615)

@iddm as I stated on #2615 a new issue would be helpful for discussion. The issue seems to be specific to you/your local environment, if libcore was panicking for everyone everywhere then yes, that'd be quite a high priority issue across a number of tools and teams.