Travis is failing

[TimNN]

I believe this is due to travis using system llvm which misses the fix backported in #36117.

---- [run-pass] run-pass/issue-36023.rs stdout ----

error: test run failed!
status: signal: 11
command: x86_64-unknown-linux-gnu/test/run-pass/issue-36023.stage2-x86_64-unknown-linux-gnu 
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[run-pass] run-pass/issue-36023.rs' panicked at 'explicit panic', /build/src/tools/compiletest/src/runtest.rs:2356
note: Run with `RUST_BACKTRACE=1` for a backtrace.

cc @eddyb

[eddyb]

@rust-lang/tools Can we do anything about this?

[nagisa]

Our best bet is to add a // ignore-travis for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases).

Implementation of such ignore directive could be implemented by injecting an environment variable COMPILETEST_IS_TRAVIS or some such (done this way) and checking for that in src/tools/compiletest/src/header.rs

[jonas-schievink]

There's no need to set an extra environment variable, just check if HAS_JOSH_K_SEAL_OF_APPROVAL is set (or TRAVIS if you're boring 😉 )

[nagisa]

@jonas-schievink but… but… what if people have HAS_JOSH_K_SEAL_OF_APPROVAL on their own systems too?

[aturon]

cc @alexcrichton

[alexcrichton]

@eddyb no we do not have existing infrastructure for this. I'd prefer to avoid // ignore-travis as that's not the relevant piece here, but rather something like // ignore-llvm-3.7 or // min-llvm-version 3.7. Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well.

That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.

[frewsxcv]

Another option would be to create a base Docker image (publishing it to Docker Hub) that is just FROM ubuntu:xenial and the appropriate steps to build whatever version of LLVM we want.

[alexcrichton]

We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)

[arielb1]

There's basically a 0% chance of us regressing that test as it's just an LLVM bug

For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.

[alexcrichton]

@arielb1 touche!