-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE with pyo3 on 1.31.0 nightly #55380
Comments
I checked we can compile it with nightly-2018-10-24-x86_64-unknown-linux-gnu |
I made a minimal example |
I tried compile with some revisions and found it can compile before #54490 is merged. |
Dunno how useful this is, but @kngwyu's minimal example can be further minimised slightly by changing line 5 to |
Same exact error |
This ICE also triggers when building the following crates:
|
Due to rust-lang/rust#55380, travis cannot compile pyportus. These failures mask other real errors. Therefore, temporarily disable travis builds of the python bindings until either: 1. we can specify rust nightly version in travis 2. ICE goes away.
Due to rust-lang/rust#55380, travis cannot compile pyportus. These failures mask other real errors. Therefore, temporarily disable travis builds of the python bindings until either: 1. we can specify rust nightly version in travis 2. ICE goes away.
Due to rust-lang/rust#55380, travis cannot compile pyportus. These failures mask other real errors. Therefore, pin travis builds to rust nightly-2018-10-23 until ICE is resolved (or pyo3 0.5.0 is released, which will resolve this).
Due to rust-lang/rust#55380, travis cannot compile pyportus. These failures mask other real errors. Could not pin travis builds to rust nightly-2018-10-23 until ICE is resolved (or pyo3 0.5.0 is released, which will resolve this). Disable travis builds of python bindings temporarily.
I just stumbled upon this again while analyzing some ICEs on crater runs. |
This regression seems to depend on specialization, which is unstable, so this is a nightly-to-nightly Of course, this is indeed a regression and should be resolved, but there is no point in e.g. beta-nominating it. |
Ah sorry, my bad then (being the one asking for the |
No problem. I just wanted us on the compiler team to be aware of what is going on here. |
Even more minified: #![feature(specialization)]
pub trait Foo {
fn abc();
fn def();
}
pub trait Marker {}
impl Marker for () {}
impl<T> Foo for T {
default fn abc() {}
default fn def() {}
}
impl<T: Marker> Foo for T {
fn def() {
Self::abc();
}
}
fn main() {
<()>::def();
<i32>::def();
} |
I think I found the bug, but not the commit that introduced the regression (am testing locally). I think #54490 was responsible for the regression? (It is not to blame for the bug). |
The fix is fundamentally:
|
dropping the param-env on the floor is obviously the wrong thing to do. The ICE was probably exposed by rust-lang#54490 adding the problem-exposing use of `traits::find_associated_item`. Fixes rust-lang#55380.
…=nikomatsakis pass the parameter environment to `traits::find_associated_item` dropping the param-env on the floor is obviously the wrong thing to do. The ICE was probably exposed by rust-lang#54490 adding the problem-exposing use of `traits::find_associated_item`. Fixes rust-lang#55380. r? @nikomatsakis
…=nikomatsakis pass the parameter environment to `traits::find_associated_item` dropping the param-env on the floor is obviously the wrong thing to do. The ICE was probably exposed by rust-lang#54490 adding the problem-exposing use of `traits::find_associated_item`. Fixes rust-lang#55380. r? @nikomatsakis
Pyo3 used to compile on 1.30 nightly, but is now failing with an ICE on 1.31
The text was updated successfully, but these errors were encountered: