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

run-pass/issue-36023.rs is failing with 1.12 on GNU/Linux #36835

Closed
sylvestre opened this issue Sep 29, 2016 · 4 comments
Closed

run-pass/issue-36023.rs is failing with 1.12 on GNU/Linux #36835

sylvestre opened this issue Sep 29, 2016 · 4 comments

Comments

@sylvestre
Copy link
Contributor


executing x86_64-unknown-linux-gnu/stage2/bin/rustc /tmp/rust/src/test/run-pass/issue-36023.rs -L x86_64-unknown-linux-gnu/test/run-pass/ --target=x86_64-unknown-linux-gnu -L x86_64-unknown-linux-gnu/test/run-pass/issue-36023.stage2-x86_64-unknown-linux-gnu.run-pass.libaux -C prefer-dynamic -o x86_64-unknown-linux-gnu/test/run-pass/issue-36023.stage2-x86_64-unknown-linux-gnu -C link-args=-Wl,-z,relro --cfg rtopt -C rpath -O -L x86_64-unknown-linux-gnu/rt
------stdout------------------------------

------stderr------------------------------
warning: unused variable: `s`, #[warn(unused_variables)] on by default
  --> /tmp/rust/src/test/run-pass/issue-36023.rs:25:12
   |
25 | fn env_var(s: &str) -> Result<String, VarError> {
   |            ^


------------------------------------------
[...]

thread '[run-pass] run-pass/issue-36023.rs' panicked at 'explicit panic', /tmp/rust/src/tools/compiletest/src/runtest.rs:2350
stack backtrace:
   1:     0x7fa28190b69b - std::sys::backtrace::tracing::imp::write::h00e948915d1e4c72
   2:     0x7fa28191d03f - std::panicking::default_hook::_{{closure}}::h7b8a142818383fb8
   3:     0x7fa28191b42e - std::panicking::default_hook::h41cf296f654245d7
   4:     0x7fa28191bc15 - std::panicking::rust_panic_with_hook::h4cbd7ca63ce1aee9
   5:     0x55621ad368df - std::panicking::begin_panic::heb5541c22bb99ccf
   6:     0x55621ad754b2 - compiletest::runtest::ProcRes::fatal::he3e6a0704948ae1c
   7:     0x55621ad6db33 - compiletest::runtest::TestCx::fatal_proc_rec::h6c036520f7a73143
   8:     0x55621ad5ab66 - compiletest::runtest::TestCx::run_rpass_test::hee1ffcb823c4f834
   9:     0x55621ad39a27 - _<F as alloc..boxed..FnBox<A>>::call_box::h335c21840425c8a0
  10:     0x7fa282044a08 - std::panicking::try::do_call::h63a911edf59441a1
  11:     0x7fa28192ae96 - __rust_maybe_catch_panic
  12:     0x7fa28204b113 - _<F as alloc..boxed..FnBox<A>>::call_box::h3db4d78fb37007ad
  13:     0x7fa2819196a2 - std::sys::thread::Thread::new::thread_start::h4c0ad33b336bc6ea
  14:     0x7fa280e27463 - start_thread
  15:     0x7fa28135097e - __clone
  16:                0x0 - <unknown>


failures:
    [run-pass] run-pass/issue-36023.rs

test result: FAILED. 2496 passed; 1 failed; 3 ignored; 0 measured

thread 'main' panicked at 'Some tests failed', /tmp/rust/src/tools/compiletest/src/main.rs:293
stack backtrace:
   1:     0x7fa28190b69b - std::sys::backtrace::tracing::imp::write::h00e948915d1e4c72
   2:     0x7fa28191d03f - std::panicking::default_hook::_{{closure}}::h7b8a142818383fb8
   3:     0x7fa28191b4ad - std::panicking::default_hook::h41cf296f654245d7
   4:     0x7fa28191bc15 - std::panicking::rust_panic_with_hook::h4cbd7ca63ce1aee9
   5:     0x55621ad368df - std::panicking::begin_panic::heb5541c22bb99ccf
   6:     0x55621ad79955 - compiletest::main::h9488a95819777ee7
   7:     0x7fa28192ae96 - __rust_maybe_catch_panic
   8:     0x7fa28191a8cd - std::rt::lang_start::h53bf99b0829cc03c
   9:     0x7fa2812882b0 - __libc_start_main
  10:     0x55621ad32d69 - _start
  11:                0x0 - <unknown>

@sylvestre sylvestre changed the title run-pass/issue-36023.rs is failing on GNU/Linux run-pass/issue-36023.rs is failing with 1.12 on GNU/Linux Sep 29, 2016
@alexcrichton
Copy link
Member

@sylvestre is this on the master branch? This test was recently tagged with // min-llvm-version 3.9 so if you're building against LLVM 3.8 and the test harness isn't up-to-date it'll fail on 3.8 (as this is a bug in LLVM 3.8)

@sylvestre
Copy link
Contributor Author

Nope, with the 1.12 release using llvm 3.8

@alexcrichton
Copy link
Member

Ah yes, I believe that the first release with the support for "min-llvm-version" is 1.13, so it should be safe to ignore this test in 1.12 for now. (does that work for you?)

@sylvestre
Copy link
Contributor Author

Sure, I removed the test already 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants