Skip to content
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

Stack overflow when impl'ing on recursive types #15188

Closed
apoelstra opened this issue Jun 25, 2014 · 9 comments
Closed

Stack overflow when impl'ing on recursive types #15188

apoelstra opened this issue Jun 25, 2014 · 9 comments
Labels
A-typesystem Area: The type system

Comments

@apoelstra
Copy link
Contributor

See https://gist.github.com/apoelstra/0c5e05a2d57a91be3c0b

Here I have a structure like

struct List<T> {
data: T,
next: Option<Box<List<T>>>
}

and am trying to implement a deserialization trait on it. When I try to call deserialize on a Vec<u8> to produce a List<u8> say, rustc overflows, presumably chasing <T> through an infinite chain of Option<Box<List<T>>>s somehow.

Note that if the data field and parameter <T> are removed, there is no stack overflow.

@apoelstra
Copy link
Contributor Author

This is similar to #11824 but I don't believe it is the same bug since #11824 triggers just by defining the Trait, while this requires an actual call to a trait method.

@apoelstra
Copy link
Contributor Author

After some experimentation I have determined that the cause of the recursion is that the exact type of I:Iterator is propagated from the original function call List<T>::deserialize, through to called deserialization routines as ByRef<I>, through to List<T>::deserialize again, through as ByRef<ByRef<I>>, and so on.

So now I am unsure if this is an actual bug.

@chris-morgan
Copy link
Member

I would classify a stack overflow as a bug in rustc. If it’s not legal, it should complain with an appropriate error, not with stack overflow.

@steveklabnik steveklabnik added the A-typesystem Area: The type system label Jan 23, 2015
@steveklabnik
Copy link
Member

Triage: there have been a lot of changes to Rust since this sample code was made. @apoelstra , have you seen this error lately?

@apoelstra
Copy link
Contributor Author

No, I have not encountered this bug since I filed it.

@steveklabnik
Copy link
Member

Okay, I'm going to give it a close, then.

Anyone else coming along later, if you see this, please let me know and I'll re-open.

@rphmeier
Copy link
Contributor

rphmeier commented Feb 2, 2016

not sure about that: https://play.rust-lang.org/?gist=d202841280e5d7a9e28f&version=nightly

On nightly/beta it appears to time out, on stable it's still a stack overflow.

@rphmeier
Copy link
Contributor

rphmeier commented Feb 2, 2016

(I just ported it to stable Rust)

@steveklabnik steveklabnik reopened this Feb 2, 2016
@Mark-Simulacrum
Copy link
Member

This now provides a proper, if very long, error message:

rustc 1.18.0-nightly (128aa262e 2017-04-28)
warning: field is never used: `data`
  --> <anon>:39:3
   |
39 |   data: T,
   |   ^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

warning: field is never used: `next`
  --> <anon>:40:3
   |
40 |   next: Option<Box<List<T>>>
   |   ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

warning: unused variable: `deserialize`
  --> <anon>:55:7
   |
55 |   let deserialize: Result<List<u8>, _> = Serial::deserialize(serialized.iter().map(|x| *x));
   |       ^^^^^^^^^^^
   |
   = note: #[warn(unused_variables)] on by default

error[E0275]: overflow evaluating the requirement `<std::slice::Iter<u8> as std::iter::Iterator>::Item`
  |
  = help: consider adding a `#![recursion_limit="512"]` attribute to your crate
  = note: required because of the requirements on the impl of `std::iter::Iterator` for `std::iter::Map<std::slice::Iter<u8>, [closure@<anon>:55:84: 55:90]>`
  = note: required because of the requirements on the impl of `std::iter::Iterator` for `&mut std::iter::Map<std::slice::Iter<u8>, [closure@<anon>:55:84: 55:90]>`
   .... snip 200+ lines

error: aborting due to previous error

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2023
Use debug impl in rendering const eval result

fix rust-lang#15188
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

5 participants