[regression] rustc panic on nightly (0667ae9 2016-05-17): Encountered errors `[FulfillmentError(Obligation(predicate=Binder(TraitPredicate #33723
Assignees
Labels
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-high
High priority
regression-from-stable-to-beta
Performance or correctness regression from stable to beta.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
sanxiyn
added
the
I-ICE
|
@xen0n That's odd. Could you post a backtrace ( |
|
@arielb1 It's like this on latest nightly (179539f), zetok/tox@8c63279: |
|
The same backtrace with my debug build: |
|
… Now this crap also breaks beta builds and is getting stabilized? WTF? |
steveklabnik
added
the
regression-from-stable-to-beta
|
Triage: it appears this is a stable-to-beta regression, so tagging. |
brson
added
I-nominated
T-compiler
|
cc @michaelwoerister related to the item collector? @rust-lang/compiler This is a pretty ugly regression that is going to hit stable very soon. Can you consider it? |
|
If we don't manage fix the bug in time, we can turn off item collection for the next stable release. The results of the collector are only used for auto-tests so far. |
|
assigning to self to reduce to test case (and maybe fix) |
|
Okay, I reduced the problem down to this relatively simple regression "standalone" test against the extern crate quickcheck;
#[test]
fn send_nodes_to_bytes_test() {
use self::quickcheck::{Arbitrary, Gen, quickcheck};
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
struct PackedNode;
/// Valid, random PackedNode.
impl Arbitrary for PackedNode {
fn arbitrary<G: Gen>(_: &mut G) -> Self { unimplemented!() }
}
fn with_nodes(_: PackedNode, _: Option<PackedNode>) { unimplemented!() }
quickcheck(with_nodes as fn(PackedNode, Option<PackedNode>));
}A semi-interesting details is that I seem to have to use a I'm going to shift now to the |
|
Here is a standalone file that causes the ICE on a nightly // Heavily reduced version of `quickcheck` with an `fn main`that ICE's the compiler.
//
// This is for issue #33723.
pub trait Arbitrary : Clone + 'static {
fn arbitrary<G>() -> Self { unimplemented! () }
fn shrink(&self) -> Box<Iterator<Item=Self>> { unimplemented!() }
}
impl<A: Arbitrary> Arbitrary for Option<A> { }
impl<A: Arbitrary> Arbitrary for (A,)
{
fn shrink(&self) -> Box<Iterator<Item=(A,)>> {
let (ref a, ) = *self;
let srest = a
.shrink()
.scan((), |_, _| unimplemented!());
Box::new(srest)
}
}
impl<A: Arbitrary, B: Arbitrary> Arbitrary for (A, B,)
{
fn shrink(&self) -> Box<Iterator<Item=(A, B)>> {
let (ref a, ref b) = *self;
let srest = (b.clone(),)
.shrink()
.scan(a.clone(), |_, _| unimplemented!());
Box::new(srest)
}
}
pub fn quickcheck<A: Testable>(f: A) {
f.result::<A>();
}
pub trait Testable : Send + 'static {
fn result<G>(&self) { unimplemented!() }
}
impl Testable for () { }
impl<T: Testable, A: Arbitrary, B: Arbitrary> Testable for fn(A, B) -> T
{
fn result<G_>(&self) {
let a: (A, B) = Arbitrary::arbitrary::<G_>();
a.shrink();
}
}
#[derive(Clone, Debug)]
struct PackedNode;
impl Arbitrary for PackedNode { }
fn main() {
fn with_nodes(_: PackedNode, _: Option<PackedNode>) { unimplemented!() }
quickcheck(with_nodes as fn(PackedNode, Option<PackedNode>));
}I'm going to open a fresh issue with this specific test case, so that we can focus on the discussion of how to resolve this without having to scroll through the stack-traces in the thread here. |
|
While writing up #34503 and looking more carefully at the actual reported error, it seems like the problem here is that the compiler is erroneously requiring that the struct in question implement the
To be clear: There is no proper reason for the compiler to be requiring both of those traits in the case in question. But, I tried adding the following (completely fake) impl ::std::cmp::PartialOrd for PackedNode {
fn partial_cmp(&self, _: &Self) -> Option<::std::cmp::Ordering> {
unimplemented!()
}
}@zetok I am hoping we will fix the compiler bug in the meantime (and I will make sure #34503 stays open until it is fixed), but you may want to put a work-around like the above into your code in the meantime. |
I would prefer to not work around compiler bugs. As @michaelwoerister stated above, if it can't be fixed in time for release, it can be turned off. |
|
cc @pnkfelix @rust-lang/compiler There's a release next week. Is there any hope of fixing this? |
arielb1
added a commit
to arielb1/rust
that referenced
this issue
Jul 1, 2016
Fix a bug where an obligation that depend on an erroring obligation would be regarded as successful, leading to global cache pollution and random lossage. Fixes rust-lang#33723. Fixes rust-lang#34503.
bors
added a commit
that referenced
this issue
Jul 2, 2016
fail obligations that depend on erroring obligations Fix a bug where an obligation that depend on an erroring obligation would be regarded as successful, leading to global cache pollution and random lossage. Fixes #33723. Fixes #34503. r? @eddyb since @nikomatsakis is on vacation beta-nominating because of the massive lossage potential (e.g. with `Copy` this could lead to random memory leaks), plus this is a regression.
alexcrichton
pushed a commit
to alexcrichton/rust
that referenced
this issue
Jul 3, 2016
Fix a bug where an obligation that depend on an erroring obligation would be regarded as successful, leading to global cache pollution and random lossage. Fixes rust-lang#33723. Fixes rust-lang#34503.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://travis-ci.org/zetok/tox/jobs/131140755#L843 ← fails on 1.10.0-nightly (0667ae9 2016-05-17)
https://travis-ci.org/zetok/tox/jobs/131120373 ← worked on the previous build(s) – 1.10.0-nightly (cd6a400 2016-05-16)
Newest nightly fails to compile something that compiled just fine for ~weeks across all Rust channels.
Fails also on osx builds.
The text was updated successfully, but these errors were encountered: