-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
rustc stackoverflow #25954
Labels
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Comments
jdm
added
the
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
label
Jun 2, 2015
Reduced testcase (only cleanup, not really significant) use std::cell::{Cell, RefCell};
struct A<T: Fn()> {
x: RefCell<Option<T>>,
b: Cell<i32>,
}
fn main() {
let mut p = A{x: RefCell::new(None), b: Cell::new(4i32)};
let q = || p.b.set(5i32);
*(p.x.borrow_mut()) = Some(q);
} |
Further reduced: struct B<F: Fn()> (F);
fn main() {
let mut p = B(std::mem::zeroed());
p.0 = ||{p.0;} ;
} |
😊 nice |
The recursion is inside check::regionck::type_must_outlive |
robertg
added a commit
to robertg/rust
that referenced
this issue
Jun 22, 2015
Display E0399 and stop recursing in type_must_outlive if a previous function application was encountered.
I'm curious what is the origin of this example? |
So the core problem is that closure types can contain themselves. In PR #27087, I changed how closures are desugared, preventing cyclic closures and thus sidestepping this problem. |
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Jul 24, 2015
…is now impossible.
bors
added a commit
that referenced
this issue
Jul 24, 2015
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment. As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes #25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954. (As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.) r? @nrc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Offending program: http://is.gd/uNH2bk
The text was updated successfully, but these errors were encountered: