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

(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

triage: P-high, removing nomination label

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.

@Andlon

@Andlon Can you provide the code?

@WildCryptoFox

@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?

@Andlon

@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>.

@WildCryptoFox

@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).

@Andlon

@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.

By the way I wrote a recent blog post on generic techniques for reducing compiler bugs in Rust. It might give you ideas.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

@Andlon

@Andlon Testing with both 2019-11-24 and 2019-11-25; only the build on the 24th triggers the ICE, indicating it was fixed in the build on the 25th.

Try updating your rust-toolchain to nightly-2019-11-25.

Edit: I tested with nightly-2019-11-26 too and that does ICE!

rustup update may have avoided the newest version due to missing optional components (clippy?) for that version at the time.

I can confirm the ICE of this issue remains in play.

I think you should open a new issue.

@Andlon

@Andlon Curiously when adding default-features = false to nalgebra the ICE goes away, and stays away if you enable its std feature. This is odd because nalgebra's default only implies std and none of its code is conditional to the feature = "default".

To add to the ICE reducing tips: remove everything the dead_code lint signals (including your things renamed with the underscore prefix), set your ICE-trigger as public (and make everything else you can private), use default-features = false on dependencies to reduce features and use #[no_std] to reduce std to core.

@Andlon

@Andlon I've reduced your code by ~100 lines

@WildCryptoFox

@WildCryptoFox: that's great, thanks! As you suggested, I've opened a new issue here: #66768.

@pnkfelix

@pnkfelix I just noticed the test you included is the partially reduced variant, not the most reduced variant. Per @eddyb 's post in the previous issue. This smaller variant actually triggers two MIR errors - one more than the variant above.

trait Trait {
    type Assoc;
}

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

fn unit() -> impl Into<<() as Trait>::Assoc> {}

pub fn ice() {
    Into::into(unit());
}

It looks like this is cauesd by the un-normalized projection <() as Trait>::Assoc appearing in the result of tcx.predicate_of for the opaque return type of unit. This causes SelectionContext.match_projection_obligation_against_definition_bounds to fail to find a candidate from the opaque type's predicates, resulting in the ICE.

I've not entirely certain where the normalization should be taking place. Should tcx.predicates_of perform the normalization, or should SelectionContext be doing it?

Should tcx.predicates_of perform the normalization

AFAIK no, predicates_of should be "as written", and the caller should do any necessary normalization. (pretty sure lazy normalization of associated type projections would fix this)

Update: This still triggers an ICE on the latest nightly.

Update: This still triggers an ICE on the latest nightly.

(Still triggers ICE on latest nightly)

Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

Auto merge of rust-lang#77741 - JohnTitor:add-tests, r=matthewjasper

Navigation Menu

Repository navigation

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

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

pnkfelix commented on Oct 31, 2019

Andlon commented on Nov 22, 2019

WildCryptoFox commented on Nov 23, 2019

Andlon commented on Nov 23, 2019

WildCryptoFox commented on Nov 23, 2019

Andlon commented on Nov 23, 2019

WildCryptoFox commented on Nov 23, 2019

pnkfelix commented on Nov 23, 2019

7 remaining items

WildCryptoFox commented on Nov 26, 2019

WildCryptoFox commented on Nov 26, 2019

WildCryptoFox commented on Nov 26, 2019

Andlon commented on Nov 26, 2019

WildCryptoFox commented on Nov 26, 2019

Aaron1011 commented on Jan 3, 2020

eddyb commented on Jan 16, 2020

WildCryptoFox commented on May 13, 2020

WildCryptoFox commented on Aug 17, 2020

JohnTitor commented on Oct 7, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions