Enable LLDB debug info tests on CI

[EFanZh]

This PR tries to enable LLDB debug info tests on CI, so that unintentional changes to LLDB debug info can be detected.

[EFanZh]

I have observed that several tests were broken, which I marked NOT WORKING, and some pretty printing style has changed, not sure if they were intentional.

[rustbot]

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Kobzol]

CC @saethlin I remember you having thoughts on how we should run debugger tests on CI. Personally, I would love for our debugger support to improve, of course, but I'm not sure if we actually have someone working on debugging at the moment and if the debugger support is at a reasonable enough level for us to re-enable the tests.

[saethlin]

The problem with the debuginfo tests is that they just run whatever is installed locally (the tracking issue for this problem is #126092). I ran into llvm/llvm-project#70453, which broke lldb for 2 major LLVM releases because upstream failed to backport the fix.

I have an overly negative view of the test suite because my primary interaction with it is discovering that it is completely broken. I'm aware that some people try to justify the current state of it, but I think that's just knee-jerk status quo defense and if someone tried to introduce this test suite today it would not get merged.

I don't actually work on debuginfo generation or Rust debugger support. As far as I'm aware, such work is primarily out-of-tree and mostly we just adjust our code or tests to match whatever upstream does. There is a Zulip stream #t-compiler/debuginfo but it has not had any new messages in the past 5 months.

[Kobzol]

Thank you for that context! Yeah, I'm also unsure if just enabling the test suite as-is is the best way forward. If a failure happens on CI (which will probably happen sooner, rather than later, given the historical track of debuginfo tests), it might be quite tricky to even reproduce locally, let alone debug and fix. Maybe the debuginfo test suite should go through a larger overhaul first.

@jieyouxu Do you have any opinions on the matter? :)

[jieyouxu]

The problem with the debuginfo tests is that they just run whatever is installed locally (the tracking issue for this problem is #126092). I ran into llvm/llvm-project#70453, which broke lldb for 2 major LLVM releases because upstream failed to backport the fix.

I have an overly negative view of the test suite because my primary interaction with it is discovering that it is completely broken. I'm aware that some people try to justify the current state of it, but I think that's just knee-jerk status quo defense and if someone tried to introduce this test suite today it would not get merged.

I don't actually work on debuginfo generation or Rust debugger support. As far as I'm aware, such work is primarily out-of-tree and mostly we just adjust our code or tests to match whatever upstream does. There is a Zulip stream #t-compiler/debuginfo but it has not had any new messages in the past 5 months.

I agree with this assessment, but I also do not work on debuginfo generation or debugger support or debug visualizer support. These aspects primarily rely on out-of-tree contributions indeed. AFAIK the debuginfo WG is not active.

The state of debuginfo tests is really not great. Even in this PR

The official LLDB symbolic links seems to be broken

We also really do not have expertise on {gdb, lldb, cdb}. You can find the meta tracking issue for debuginfo test suites at #134682.

If tests in this PR fails, I'm fairly sure contributors will just disable them gradually, because it's a pain to run and rebless locally (you have to match exact debugger versions, possibly same arch, possibly same OS too).

[EFanZh]

Actually, not being able to easily run these tests locally is the main reason why I want to enable these tests on CI. For example, if I want to make some changes to the standard library, I think it’s better to not break currently working debug pretty printers. Since these test are not enabled on CI, it’s difficulty to develop locally or reason about the correctness of my change.

[Kobzol]

Well even though it's a bit sad, I think that the current state is more or less "we have no functioning test suite", so when we do debuginfo improvements, we should treat it as if we had no test suite, I guess?

I think that the suite should be first improved (across multiple axes) before we re-enable it on CI. Otherwise we will probably disable them soon anyway.