Port backtrace-rs test-crates to rustc repo

[workingjubilee]

backtrace-rs has a number of subcrates which it uses to test more complicated logic that is harder to observe from inside a program, leading to this exciting yaml: https://github.com/rust-lang/backtrace-rs/blob/6fa4b85b9962c3e1be8c2e5cc605cd078134152b/.github/workflows/main.yml#L54-L69

while tests inside backtrace's library itself will be run as part of the stdlib's test suite, these are not. backtrace-rs failed to run nightly testing for Windows, which would have caught this. however, many of these tests are directly relevant to rustc's functionality as well, and changes should not be landed in rustc which break them without very good reason. failing to include these tests led to a severe regression in backtraces on Windows. these tests should be ported to run inside rustc's existing test infrastructure where they are relevant. I have excepted one which was already based on a rustc test and one which is only relevant for backtrace-rs.

• cpp_smoke_test: @izarma
• debuglink is run with the following scripts
  • https://github.com/rust-lang/backtrace-rs/blob/6fa4b85b9962c3e1be8c2e5cc605cd078134152b/ci/debuglink-docker.sh
  • https://github.com/rust-lang/backtrace-rs/blob/6fa4b85b9962c3e1be8c2e5cc605cd078134152b/ci/debuglink.sh
• dylib-dep: @jieyouxu
• line-tables-only: @jieyouxu
• without_debuginfo

if you would like to work on porting one of these tests, please link to this issue in your PR and leave a comment to claim the test. if you are stuck, please don't hesitate to open a thread on the rust zulip! and be aware, some may be complex enough to need the new recipes infrastructure, but hopefully not. I expect all may need, however, this compiletest annotation:

//@ needs-unwind

[jieyouxu]

I'll take a stab at porting line-tables-only

[Noratrieb]

The tests using C may be able to make use of tests/auxiliary/rust_test_helpers.c.

[izarma]

Hi, I'll pick this up cpp_smoke_test

[jieyouxu]

I don't think debuglink can be easily ported over to the rustc test suite without the test suite having access to docker? The problem is that the test wants to test debug directories under /usr/lib/debug, which seems like a massive no-no without docker. I don't think there is a very elegant solution for that? Even if it was possible to run docker inside docker (as in rustc's CI), that seems to be a bad idea in itself.

[workingjubilee]

@jieyouxu I think I'll have to reimagine the test somewhat and port it myself, yeah! it can be run under the rustc test suite but it requires doing something mildly silly because what it is really doing is testing that you "don't lose track" of the debuginfo.

[workingjubilee]

The without_debuginfo test has been unblocked by #123081 landing.

[jieyouxu]

The without_debuginfo test has been unblocked by #123081 landing.

That test is also unfortunately a bit awkward because it's checking if each frame with a non-null IP has resolved symbols even if -Cdebuginfo=0... which is awkward to check with std::backtrace::Backtrace because AFAICT the frame IP is not exposed.

[ChrisDenton]

We could add more methods to BacktraceFrame. Might require an ACP though.