brainfuck
brainfuck copied to clipboard
test bf_utm ... FAILED
Output with RUST_BACKTRACE=1 cargo test
:
---- bf_utm stdout ----
thread 'bf_utm' panicked at 'called `Result::unwrap()` on an `Err` value: CycleLimit', tests/lib.rs:40:1
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
4: std::panicking::default_hook::{{closure}}
5: std::panicking::default_hook
6: std::panicking::rust_panic_with_hook
7: rust_begin_unwind
8: core::panicking::panic_fmt
9: core::option::expect_none_failed
10: core::result::Result<T,E>::unwrap
at /build/rust/src/rustc-1.42.0-src/src/libcore/result.rs:963
11: lib::bf_utm
at tests/lib.rs:12
12: lib::bf_utm::{{closure}}
at tests/lib.rs:10
13: core::ops::function::FnOnce::call_once
at /build/rust/src/rustc-1.42.0-src/src/libcore/ops/function.rs:232
14: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
15: __rust_maybe_catch_panic
16: test::run_test::run_test_inner::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Yep, this is a known issue. In fact, running cargo test
currently, this is the only failing test.
I haven't taken the time to dig more into it however, but thanks for opening an issue about it.
It seems to work fine if you provide a Turing machine as input (for example below) and increase the cycle limit over 18_827_260 (for that example).
So this is a bug in the test not the interpreter.
b1b11111111111111111bbb1b1bb11111111111111111bb111111b1b111111111111111111111bb1bb11111111111bb11111111111111111bb1111111111111111b11111111111c1c1