yet another associated type ICE (probably more missing normalize calls)

[pnkfelix]

(spawned off of #63154)

This variant of the code from #63154 still causes an ICE on nightly rustc (play):

trait Trait {
    type Assoc;
}

impl Trait for () {
    type Assoc = ();
}

trait Dummy<T> {}

impl<T> Dummy<T> for () {}

fn make<T: Trait>() -> impl Dummy<T::Assoc> {}

fn extract<T>(_: impl Dummy<T>) -> Option<T> {
    None
}

pub fn ice() {
    extract(make::<()>());
}

yields:

error: internal compiler error: broken MIR in DefId(0:26 ~ issue_63154_b[8787]::ice[0]) (NoSolution): could not prove Binder(TraitPredicate(<impl Dummy<<() as Trait>::Assoc> as Dummy<()>>))

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:391:17

[pnkfelix]

triage: P-high, removing nomination label

[Andlon]

I'm running into an issue which might be related to this, but I can't really tell if it is the same issue or not. Perhaps someone would be willing to help me determine if it is?

I'm experiencing ICEs across stable, beta and nightly. cargo check appears to work fine. I've turned off incremental compilation (e.g. export CARGO_INCREMENTAL=0), and the issue persists. I've attached the result of cargo clean && cargo build, with RUST_BACKTRACE=1.

buildlog.txt

The issue is also not entirely reproducible: on some computers, the issue is not triggered for the same code base, however when continuing to develop it will inevitably appear. Similarly, at present, I've just confirmed that compiling in release mode seems to have worked, whereas debug mode did not. I don't see any obvious patterns in what determines which configurations trigger the bug.

I don't see right now how I can reduce my code down to a minimal example, but since I'm working against an academic deadline and my code does not reliably compile right now, I'm in a bit of a pickle, and would really appreciate any pointers that could help me either properly report the bug or to resolve the issue.

[WildCryptoFox]

@Andlon Can you provide the code?

[Andlon]

@WildCryptoFox: Not publicly, at this point, unfortunately, as it contains algorithms that we need to keep a little under wraps for some time (at least until it's been accepted for publication). But it's intended to be open sourced later on, so I think it won't be a problem to provide the code to select individuals, if that could work for you?

[WildCryptoFox]

@Andlon I've pinged @eddyb who does enjoy reducing code.

Do you have a function in the form of fn make<T: Trait>() -> impl Dummy<T::Assoc>?

If so, my workaround may help you. Try transforming it as fn make<T: Trait<Assoc=Y>, Y>() -> impl Dummy<Y>.

[Andlon]

@WildCryptoFox: I don't think I have a function like that in the code that the compiler actually complains about, but there's a whole lot of generic and associated types used in various ways in general.

Actually, I looked at the code again and tried to reduce it a little, and it seems as if the problem is independent of the function signature, but instead has something to do with the interaction between nalgebra types Vector1, Vector2 and conversion to Point2, so it might be entirely unrelated to this issue after all. I'll try to see if I can reduce it further and come back to you (hopefully today, if not then tomorrow).

[WildCryptoFox]

@Andlon It might hit the same problem via a different route. Good luck with reducing. I've pinged you in a private gist. I could take a look at the code; though I'm a bit busy right now so no guarantee for when.