rustc stack overflow: pub use super::* in public inner mod.

[ptal]

The RUST_BACKTRACE=1 doesn't generate anything. I ran the compiler with valgrind and the output can be found here http://pastebin.com/TUE2WznG

rustc --version
rustc 1.0.0-dev (0430a43d6 2015-01-24 13:04:39 +0000)

[arielb1]

Yuck metadata. Could you give the code at least?

[ptal]

I don't have time to make a minimal example, you can reproduce the bug with cargo build for the project ptal/oak@e0f3568

Regex seems broken for now but you can just remove the dependency to term in the Cargo.toml, it'll stack overflow anyways.

rustc --version
rustc 1.0.0-dev (d77f6d536 2015-01-27 11:07:26 +0000)

[ptal]

Minimal example:

LibA (libA/lib.rs):

#![crate_type = "dylib"]
pub mod access
{
  pub use super::*; // <--- removing the public visibility makes the compiler not stack overflow.
}

LibB (libB/lib.rs):

#![crate_type = "dylib"]
#![feature(collections, rustc_private)]

extern crate syntax;

// One of the following item produces a `stack overflow` of rustc if
// one is commented. It's weird that it works with Deref.... The three cases:

// OK
// extern crate attribute;
// use std::ops::Deref;

// KO
extern crate attribute;
// use std::ops::Deref;

// OK
// // extern crate attribute;
// use std::ops::Deref;

pub use std::string::String;
pub use syntax::parse::token::get_ident;
pub use syntax::ast::Ident;

pub fn id_to_string(id: Ident) -> String
{
  String::from_str(get_ident(id).deref())
}

Compilation:

libA> rustc lib.rs --crate-name attribute --crate-type dylib
libB> rustc lib.rs --extern attribute=../libA/libattribute.so

thread 'rustc' has overflowed its stack

[tamird]

extern crate attribute; no longer works, so I'm not able to reproduce this.

[ptal]

I just tried this, and it still stack overflow with rustc 1.0.0-dev (9539627ac 2015-04-10) (built 2015-04-10). However, my example is misguiding because attribute is the libA, look at the --crate-name attribute option.

[steveklabnik]

Hmm, this now gives

error: unresolved import `syntax::parse::token::get_ident`. There is no `get_ident` in `syntax::parse::token`

I haven't kept up with syntax extensions to know how to update this example.

[ptal]

libB/lib.rs becomes:

#![crate_type = "dylib"]
#![feature(rustc_private)]

extern crate syntax;

// One of the following item produces a `stack overflow` of rustc if
// one is commented. It's weird that it works with Deref.... The three cases:

// OK
// extern crate attribute;
// use std::ops::Deref;

// KO
extern crate attribute;
// use std::ops::Deref;

// OK
// // extern crate attribute;
// use std::ops::Deref;

pub use std::string::String;
pub use syntax::ast::Ident;

pub fn id_to_string(id: Ident) -> String
{
  id.to_string()
}

And I have this error:

➜  libB  rustc lib.rs --extern attribute=../libA/libattribute.so
error: cannot satisfy dependencies so `std` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `core` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `collections` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `rustc_unicode` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `alloc` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `rand` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot satisfy dependencies so `libc` only shows up once
help: having upstream crates all available in one format will likely make this go away
error: cannot link together two allocators: alloc_jemalloc and alloc_system
error: aborting due to 8 previous errors

But I guess this is unrelated and that I am compiling it wrong...

[steveklabnik]

@ptal syntax extensions change all the time, and I can't figure out what "attribute" was here. Are you still seeing this bug?

[steveklabnik]

oh, looks like attribute is https://github.com/ptal/Rust.attribute which no longer compiles.

I'm going to consider this one stale and give it a close, if you can reproduce today, please let me know!