Compiler panic on rustlings exercise standard_library_types/box1.rs

[thewithz]

Steps to reproduce

curl -L https://git.io/install-rustlings | bash
cd rustlings
rustlings run box1

Use flags

gentoo /etc/portage # grep 'rust' package.use/world
# required for rust
dev-lang/rust clippy nightly parallel-compiler rls rustfmt abi_x86_64

Code

// box1.rs
//
// At compile time, Rust needs to know how much space a type takes up. This becomes problematic
// for recursive types, where a value can have as part of itself another value of the same type.
// To get around the issue, we can use a `Box` - a smart pointer used to store data on the heap,
// which also allows us to wrap a recursive type.
//
// The recursive type we're implementing in this exercise is the `cons list` - a data structure
// frequently found in functional programming languages. Each item in a cons list contains two
// elements: the value of the current item and the next item. The last item is a value called `Nil`.
//
// Step 1: use a `Box` in the enum definition to make the code compile
// Step 2: create both empty and non-empty cons lists by replacing `unimplemented!()`
//
// Note: the tests should not be changed
//
// Execute `rustlings hint box1` for hints :)

// I AM NOT DONE

#[derive(PartialEq, Debug)]
pub enum List {
    Cons(i32, List),
    Nil,
}

fn main() {
    println!("This is an empty cons list: {:?}", create_empty_list());
    println!(
        "This is a non-empty cons list: {:?}",
        create_non_empty_list()
    );
}

pub fn create_empty_list() -> List {
    unimplemented!()
}

pub fn create_non_empty_list() -> List {
    unimplemented!()
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_create_empty_list() {
        assert_eq!(List::Nil, create_empty_list())
    }

    #[test]
    fn test_create_non_empty_list() {
        assert_ne!(create_empty_list(), create_non_empty_list())
    }
}

Meta

rustc --version --verbose:

rustc 1.55.0-nightly (gentoo)
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.55.0-nightly
LLVM version: 12.0.1

Error output

✓ Successfully tested exercises/quiz3.rs
! Compiling of exercises/standard_library_types/box1.rs failed! Please try again. Here's the output:
thread '<unnamed>' panicked at 'WorkerLocal can only be used on the thread pool it was created on', /rustc/1.55.0/vendor/rustc-rayon-core/src/worker_local.rs:49:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.55.0-nightly (gentoo) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
deadlock handler panicked, aborting process

Backtrace

�c
✓ Successfully ran exercises/variables/variables1.rs!
✓ Successfully ran exercises/variables/variables2.rs!
✓ Successfully ran exercises/variables/variables3.rs!
✓ Successfully ran exercises/variables/variables4.rs!
✓ Successfully ran exercises/variables/variables5.rs!
✓ Successfully ran exercises/variables/variables6.rs!
✓ Successfully ran exercises/functions/functions1.rs!
✓ Successfully ran exercises/functions/functions2.rs!
✓ Successfully ran exercises/functions/functions3.rs!
✓ Successfully ran exercises/functions/functions4.rs!
✓ Successfully ran exercises/functions/functions5.rs!
✓ Successfully tested exercises/if/if1.rs
✓ Successfully tested exercises/if/if2.rs
✓ Successfully tested exercises/quiz1.rs
✓ Successfully ran exercises/move_semantics/move_semantics1.rs!
✓ Successfully ran exercises/move_semantics/move_semantics2.rs!
✓ Successfully ran exercises/move_semantics/move_semantics3.rs!
✓ Successfully ran exercises/move_semantics/move_semantics4.rs!
✓ Successfully ran exercises/move_semantics/move_semantics5.rs!
✓ Successfully ran exercises/primitive_types/primitive_types1.rs!
✓ Successfully ran exercises/primitive_types/primitive_types2.rs!
✓ Successfully ran exercises/primitive_types/primitive_types3.rs!
✓ Successfully tested exercises/primitive_types/primitive_types4.rs
✓ Successfully ran exercises/primitive_types/primitive_types5.rs!
✓ Successfully tested exercises/primitive_types/primitive_types6.rs
✓ Successfully tested exercises/structs/structs1.rs
✓ Successfully tested exercises/structs/structs2.rs
✓ Successfully tested exercises/structs/structs3.rs
✓ Successfully ran exercises/enums/enums1.rs!
✓ Successfully ran exercises/enums/enums2.rs!
✓ Successfully tested exercises/enums/enums3.rs
✓ Successfully ran exercises/modules/modules1.rs!
✓ Successfully ran exercises/modules/modules2.rs!
✓ Successfully tested exercises/collections/vec1.rs
✓ Successfully tested exercises/collections/vec2.rs
✓ Successfully tested exercises/collections/hashmap1.rs
✓ Successfully tested exercises/collections/hashmap2.rs
✓ Successfully ran exercises/strings/strings1.rs!
✓ Successfully ran exercises/strings/strings2.rs!
✓ Successfully ran exercises/quiz2.rs!
✓ Successfully tested exercises/error_handling/errors1.rs
✓ Successfully tested exercises/error_handling/errors2.rs
✓ Successfully ran exercises/error_handling/errors3.rs!
✓ Successfully tested exercises/error_handling/errors4.rs
✓ Successfully ran exercises/error_handling/errors5.rs!
✓ Successfully tested exercises/error_handling/errors6.rs
✓ Successfully ran exercises/generics/generics1.rs!
✓ Successfully tested exercises/generics/generics2.rs
✓ Successfully tested exercises/generics/generics3.rs
✓ Successfully ran exercises/option/option1.rs!
✓ Successfully ran exercises/option/option2.rs!
✓ Successfully ran exercises/option/option3.rs!
✓ Successfully tested exercises/traits/traits1.rs
✓ Successfully tested exercises/traits/traits2.rs
✓ Successfully tested exercises/tests/tests1.rs
✓ Successfully tested exercises/tests/tests2.rs
✓ Successfully tested exercises/tests/tests3.rs
✓ Successfully tested exercises/quiz3.rs
! Compiling of exercises/standard_library_types/box1.rs failed! Please try again. Here's the output:
thread '<unnamed>' panicked at 'WorkerLocal can only be used on the thread pool it was created on', /rustc/1.55.0/vendor/rustc-rayon-core/src/worker_local.rs:49:17
stack backtrace:
   0:     0x7f64443ece80 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf48fdf16c0426b4d
   1:     0x7f644445a9fc - core::fmt::write::h593461151db03f2b
   2:     0x7f64443de765 - <unknown>
   3:     0x7f64443f0bdb - <unknown>
   4:     0x7f64443f06b1 - <unknown>
   5:     0x7f6444d71efe - <unknown>
   6:     0x7f64443f1409 - std::panicking::rust_panic_with_hook::h8dc50bc2116bf1f6
   7:     0x7f6448438fb4 - <unknown>
   8:     0x7f6448438f8c - <unknown>
   9:     0x7f6444b7e37c - <unknown>
  10:     0x7f64482c5013 - <unknown>
  11:     0x7f6448170a63 - <unknown>
  12:     0x7f644854221d - <unknown>
  13:     0x7f64492990bb - <unknown>
  14:     0x7f64493114bb - <unknown>
  15:     0x7f6449311738 - <unknown>
  16:     0x7f64492a82ee - <unknown>
  17:     0x7f64493124a5 - rustc_middle::ty::print::pretty::<impl core::fmt::Display for rustc_middle::ty::Predicate>::fmt::h7fe01daf648ad31d
  18:     0x7f644445a9fc - core::fmt::write::h593461151db03f2b
  19:     0x7f644444db0c - alloc::fmt::format::h5f1a2cb982780923
  20:     0x7f6448796a6b - <unknown>
  21:     0x7f64484b8b11 - <unknown>
  22:     0x7f6448327a6e - <unknown>
  23:     0x7f64485413cd - <unknown>
  24:     0x7f6448720312 - rustc_query_impl::plumbing::QueryCtxt::deadlock::ha97dc3a3715a43a9
  25:     0x7f6444f15c62 - <unknown>
  26:     0x7f6444f5df62 - <unknown>
  27:     0x7f6444e9d9cb - <unknown>
  28:     0x7f6444f18663 - <unknown>
  29:     0x7f64443fd997 - <unknown>
  30:     0x7f644417be1e - start_thread
  31:     0x7f64442949cf - __clone
  32:                0x0 - <unknown>

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.55.0-nightly (gentoo) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
deadlock handler panicked, aborting process

Type 'hint' or open the corresponding README.md file to get help or type 'clear' to clear the screen.

[the8472]

rustc 1.55.0-nightly (gentoo)

This seems to be a distro-specific rust build. Does it happen on official builds too? If not then it would be more appropriate to report it to the distro maintainers.

[Mark-Simulacrum]

Just at a glance, it looks like gentoo is enabling the parallel-compiler flag (though I'm not sure) -- https://github.com/gentoo/gentoo/blob/master/dev-lang/rust/rust-1.55.0.ebuild#L44, so I'd guess that's the root cause of this bug. We don't ship a parallel compiler ourselves to users nor do we test it, so I'm not too surprised it's possible to trigger bugs with that configuration.

[thewithz]

I spun up an ubuntu 21.04 vm with rust nightly-1.57.0 which worked correctly, and I did emerge dev-lang/rust with the parallel-compiler USE flag. I edited them into the post at the top. I disabled the parallel-compiler USE flag and rebuilt world and no longer receive the deadlock handler panic, so I will move this issue over to the gentoo bugzilla tracker.

[gyakovlev]

@Mark-Simulacrum just to be clear, gentoo provides an option to toggle parallel-compiler on. It's disabled by default and "masked"/marked as unstable, so users have to opt-in in quite an explicit way to enable it.

from rust developer point of view, is there a value in such an option or should we simply not expose it and it has no future?

our goal is to provide useful options for users, but also we don't want to generate too much noise if this option does not have a meaningful future. but our users find some stuff we expose useful indeed, because they can't sometimes get it via rustup, and it's easier for them to build rust via our package manager than directly from source.

[Mark-Simulacrum]

I don't think it's a problem, just be aware it's not a tested configuration currently by us, so it can break like in this issue (or in theory silently miscompile but I wouldn't expect that). If that sort of option is reasonable to expose, it seems fine to me, though I do worry a little that folks will enable it just seeking faster compiles without knowing the tradeoff.

[gyakovlev]

thanks for reply.
I've edited exposed flag description to read
<flag name="parallel-compiler">Build a multi-threaded rustc (experimental, unsupported)</flag>
I may change unsupported -> untested though later, seems to be more fitting wording.

[Enselic]

Triage: Closing since this happens with an unofficial build. Feel free to reopen if this can be reproduced with the official compiler, along with step-by-step instructions on how to do so.