Stack overflow in rustc using unboxed closure bounds #21410
Labels
A-closures
Area: Closures (`|…| { … }`)
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Comments
|
Actually, nevermind me, I misunderstood the issue. Re-opening. |
Gankra
added
A-closures
|
Triage: still overflows. |
bors
added a commit
that referenced
this issue
Nov 11, 2017
[WIP] move closure kind, signature into `ClosureSubsts`
Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects:
- It means that the closure's type changes as inference finds out more things, which is very nice.
- As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators).
- It avoids cyclic closures calls.
- These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410).
We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed.
r? @arielb1
bors
added a commit
that referenced
this issue
Nov 13, 2017
[WIP] move closure kind, signature into `ClosureSubsts`
Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects:
- It means that the closure's type changes as inference finds out more things, which is very nice.
- As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators).
- It avoids cyclic closures calls.
- These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410).
We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed.
r? @arielb1
bors
added a commit
that referenced
this issue
Nov 21, 2017
move closure kind, signature into `ClosureSubsts`
Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects:
- It means that the closure's type changes as inference finds out more things, which is very nice.
- As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators).
- It avoids cyclic closures calls.
- These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410).
We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed.
r? @arielb1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Attempting to compile this causes rustc to stack overflow:
There are other stack overflow issues with recursive traits that seem like they are probably related (#15477 seems like the closest match--maybe #12511, #11824, others?) But they are all about declaring new traits, and here I have it overflowing using only the built in unboxed closure traits. (
FnOncecan be replaced withFnorFnMutand it still reproduces the crash, but I can't produce it with anything not involving a closure.) The use of the closure's own type can be either in a parameter or in the return type--this produces a similar crash:The crash only happens when you actually try to use the function
g--just declaring it is accepted (with an appropriate warning about dead code.)Running a backtrace I found the following frames repeated until overflow:
and started with this:
The presence of
closure_to_stringin the repeating stack frames makes me think it's something specific to closures, rather than just a special case of one of the already-filed issues affecting traits in general.The text was updated successfully, but these errors were encountered: