Port backtrace's cpp_smoke_test to rustc repo

[Pyr0de]

Ported backtrace-rs test crates cpp_smoke_test to rust repo.

issue #122899

[rustbot]

Could not assign reviewer from: workingjubilee.
User(s) workingjubilee are either the PR author, already assigned, or on vacation. Please use r? to specify someone else to assign.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @fmease (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[jieyouxu]

Maybe r? @workingjubilee (or @ChrisDenton)

[rustbot]

Could not assign reviewer from: workingjubilee.
User(s) workingjubilee are either the PR author, already assigned, or on vacation. Please use r? to specify someone else to assign.

[jieyouxu]

Right. r? @ChrisDenton (or idk someone else who's more familiar with backtrace)

[ChrisDenton]

This test is intentionally testing C++ so it will need to be a cpp file. Also the backtrace feature cpp_demangle will need to be enabled for the test.

Though looking at this further, it seems like it's been "temporarily" ignored in backtrace-rs for eight years? https://github.com/rust-lang/backtrace-rs/blob/e33eaac8caf46d0d3cc57f8d152529e8b7ae1b78/crates/cpp_smoke_test/tests/smoke.rs#L11
Ah it seems that the reason it was ignored has long since been fixed: gimli-rs/cpp_demangle#73

[Pyr0de]

Hey,
Can I add this test to tests/run-make?

and how can I use the feature cpp_demangle?
I doesn't seem to be present in std::backtrace

[Pyr0de]

Hey @ChrisDenton,
I do not see any way to use the feature cpp_demangle.
There is also no function exposed by std::backtrace that can be used to get the demangled function name from the frame. BacktraceFrames

If there is some work around to get the demangled name, please do let me know

[ChrisDenton]

@Pyr0de I mean you can just use run_make_support::cargo() with a --manifest-path argument set to the cpp_smoke_test/Cargo.toml. That should take care of setting features, etc.

[Pyr0de]

Oh, thanks for the suggestion
I'll give it a shot

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[Pyr0de]

The test is mostly the same from cpp_smoke_test, just made some changes for it to successfully run and added the rmake.rs file

@rustbot review

[jieyouxu]

I can only comment on the rmake.rs test file itself, not on the actual test logic.

[ChrisDenton]

looks good to me if @jieyouxu is happy with the rmake test

[jieyouxu]

I'll read this test again a bit later

[jieyouxu]

Oh this is slightly problematic because now the run-make test is calling out to cargo test which is its own test runnner wrapper on top of libtest, just like compiletest, which is very strange. This should be able to be a plain rmake.rs without cargo being involved. I'll take a stab tmrw at slightly rewriting this test.

Generally speaking, using cargo inside rmake.rs to build something (like a nested crate in a run-make test) is fine, but using cargo test inside rmake.rs is undesirable because it's really really opaque and another thicc layer of indirection in testing. (Notably, we're already run by libtest by the time the test recipe binary is executed!)

The current formulation of the test is also exercising the crates.io version of some backtrace, not necessarily the backtrace shipped alongside std.

[jieyouxu]

So I had an attempt over at #136695 to not depend on cargo test. Along the way I found out this test is quite problematic. It's super fragile and sensitive to opt levels and debuginfo level of the C++ file in conjunction with the rust file, and the test (or at least the assertion) does not seem to work on msvc at all.

[workingjubilee]

Given its difficulties, I have struck the test from the list of tests we want to port.

[Pyr0de]

Will this test also fail like how @jieyouxu's test failed?

[jieyouxu]

Will this test also fail like how @jieyouxu's test failed?

Yes, provided how sensitive this test is to debuginfo-level + opt-level + platform/env for the combination of the C++ lib + Rust binary. It didn't work on msvc no matter what configuration I tried, nor does it work on apple targets where I ran a try-job.

@Pyr0de I'm going to close this and the other attempt over at #136695 based on how fragile this test is + its difficulty to implement versus the value it may or may not provide. Thank you for taking a shot at this though, and while this didn't work out, I find discovering what doesn't work here to be equally valuable.

[Pyr0de]

Even though it didn't work, thanks for all the help with this PR