Using Self::default() instead of TypeAlias::default() causes an ICE on nightly.

[rodrimati1992]

In the process of adding my project to travis-ci I got a nightly ICE from using "Self::default() instead of TypeAlias::default()" inside an impl block for type aliases.This works fine on stable.

This is the log for the first error:
https://travis-ci.org/rodrimati1992/type_level/jobs/436599429

This is the log for the second error:
https://travis-ci.org/rodrimati1992/type_level/jobs/436607478

This are the changes made to add the project to travis-ci,
including the commits that fix the error in my project:
rodrimati1992/type_level@9411158

The files that were changed to fix the error were :

• type_level_examples/src/bin/_03_vis_wrapper.rs

• type_level_examples/src/bin/_07_split_mut.rs

[estebank]

Could you help us narrow down which nightly introduced the problem for you? How recently were you able to build before the current issue?

Particularly, I'm intrigued by #53751, namely nightly from September 12th vs 14th and #54346 September 19th vs 21st.

[estebank]

Nevermind, I believe I found the culprit https://github.com/rust-lang/rust/pull/52568/files#diff-2c49ea48a32b1e12546e0517e544ef58R315

@oli-obk can you take a look? I'm not sure I understand why we're panicing in that case instead of always emitting or at least cancelling those diagnostics.

[rodrimati1992]

I will try this in those nightlys anyway and report which ones break.

[rodrimati1992]

I tested on the rust nightly versions listed bellow on
the commit (41393e6e0e23a093709c6661ccc728ae07c621ec)

Works fine in nightly-2018-08-19-i686-unknown-linux-gnu .
Works fine in nightly-2018-08-25-i686-unknown-linux-gnu .
On nightly-2018-08-26-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-08-28-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-08-30-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-09-01-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-09-10-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-09-12-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-09-14-i686-unknown-linux-gnu I get the same error as the first comment.
On nightly-2018-09-19-i686-unknown-linux-gnu I get the same error as the first comment.

The output is long enough that I appended some files with their output.

2018-08-26-error.txt
2018-08-28-error.txt
2018-08-30-error.txt
2018-09-01-error.txt
2018-09-10-error.txt
2018-09-12-error.txt
2018-09-14-error.txt
2018-09-19-error.txt

[oli-obk]

The actual error is

error: internal compiler error: broken MIR in DefId(0/0:10 ~ _03_vis_wrapper[21d9]::rectangle[0]::{{impl}}[0]::new[0]) (const std::default::Default::default): bad constant user type Canonical { variables: [], value: fn() -> rectangle::RectangleInner<type_level_values::const_wrapper::ConstWrapper<<type_level_RectangleAcessible::ConstRectangleAcessible<type_level_values::reexports::Void, type_level_values::reexports::Void> as type_level_values::field_traits::SetField_<type_level_RectangleAcessible::__fields::All, type_level_Accessibility::Accessible>>::Output, type_level_values::const_wrapper::PhantomKind>> {<rectangle::RectangleInner<type_level_values::const_wrapper::ConstWrapper<<type_level_RectangleAcessible::ConstRectangleAcessible<type_level_values::reexports::Void, type_level_values::reexports::Void> as type_level_values::field_traits::SetField_<type_level_RectangleAcessible::__fields::All, type_level_Accessibility::Accessible>>::Output, type_level_values::const_wrapper::PhantomKind>> as std::default::Default>::default} } vs fn() -> rectangle::RectangleInner<type_level_values::const_wrapper::ConstWrapper<type_level_RectangleAcessible::ConstRectangleAcessible<type_level_Accessibility::Accessible, type_level_Accessibility::Accessible>, type_level_values::const_wrapper::PhantomKind>> {<rectangle::RectangleInner<type_level_values::const_wrapper::ConstWrapper<type_level_RectangleAcessible::ConstRectangleAcessible<type_level_Accessibility::Accessible, type_level_Accessibility::Accessible>, type_level_values::const_wrapper::PhantomKind>> as std::default::Default>::default}: NoSolution
  --> type_level_examples/src/bin/_03_vis_wrapper.rs:42:13                                             
   |                                                                                                   
42 |             Self::default()                                                                       
   | 

The panic! quoted in https://github.com/rust-lang/rust/pull/52568/files#diff-2c49ea48a32b1e12546e0517e544ef58R315 is just a way to abort the compiler after dumping all the ICEs

[Centril]

@rodrimati1992 Could you produce a minimal example for this? Also, does it reproduce on the current nightly?

[rodrimati1992]

I'll leave it at can't reproduce with a minimal example,I tried to but couldn't.

I haven't touched the type_level repository since december 2018(nor used it),and the type_level_values crate hasn't been able to compile due to recursive impl errors since then,so the documentation example that triggers this ICE wouldn't run anyway.

[spastorino]

@rustbot ping icebreakers-cleanup-crew

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @KarlK90 @LeSeulArtichaut @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

[spastorino]

Sorry, I was a bit fast to ping the cleanup-crew group.

In an ideal world what we would like to do is to go back to the rustc version where this started to manifest and try to get an MVCE and then try to see if this is still an issue in current rustc versions.

However, the bug as written is based on abandoned code and it's kind of non actionable for us.

[spastorino]

After going over this with @pnkfelix we decided to tag as P-low with the intention to close it because it's kind of non actionable for us.

[spastorino]

Closing this as non actionable as per comment from last triage meeting. If someone wants to provide an MCVE and something that is more actionable, please feel free to comment and we can reopen this issue.