Code change:
<ins> // build-pass // // (this is deliberately *not* check-pass; I have confirmed that the bug in // question does not replicate when one uses `cargo check` alone.) pub enum Void {} enum UninhabitedUnivariant { _Variant(Void), } enum UninhabitedMultivariant2 { _Variant(Void), _Warriont(Void), } enum UninhabitedMultivariant3 { _Variant(Void), _Warriont(Void), _Worrynot(Void), } #[repr(C)] enum UninhabitedUnivariantC { _Variant(Void), } #[repr(i32)] enum UninhabitedUnivariant32 { _Variant(Void), } fn main() { let _seed: UninhabitedUnivariant = None.unwrap(); match _seed { UninhabitedUnivariant::_Variant(_x) => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Variant(_x) => {} UninhabitedMultivariant2::_Warriont(_x) => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Variant(_x) => {} _ => {} } let _seed: UninhabitedMultivariant2 = None.unwrap(); match _seed { UninhabitedMultivariant2::_Warriont(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Variant(_x) => {} UninhabitedMultivariant3::_Warriont(_x) => {} UninhabitedMultivariant3::_Worrynot(_x) => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Variant(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Warriont(_x) => {} _ => {} } let _seed: UninhabitedMultivariant3 = None.unwrap(); match _seed { UninhabitedMultivariant3::_Worrynot(_x) => {} _ => {} } let _seed: UninhabitedUnivariantC = None.unwrap(); match _seed { UninhabitedUnivariantC::_Variant(_x) => {} } let _seed: UninhabitedUnivariant32 = None.unwrap(); match _seed { UninhabitedUnivariant32::_Variant(_x) => {} } } </ins>

Related discussion:
text: cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.