bootstrap: remove lldb dist packaging

[RalfJung]

The lldb-preview rustup package is missing on every single target, and has never been shipped beyond x86_64-apple-darwin. It was removed in #62592 which landed around a year ago, and there's not been demand that we re-enable it since, so we're now removing support entirely to cleanup the code a bit.

The hope is that this will also kill the useless "lldb-preview" row on https://rust-lang.github.io/rustup-components-history/.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

r? @Mark-Simulacrum

LLDB was disabled in #62592, nearly a year ago. My guess is since I haven't seen anything since then suggesting re-enabling it we can also remove support (can always resurrect the small amount of support left from git history anyway).

I think we'll want to remove the options related to lldb as well; probably the best way to do that is to remove the lldb_enabled on config and then handle rustc errors from there. We'll also want to drop the configure.py --lldb option.

[RalfJung]

@Mark-Simulacrum okay, I did that. And then in the last commit I removed some more things that looked outdated, but I am not sure I understand enough of this so please check carefully.

Remaining occurrences of "lldb":

src/bootstrap/test.rs
1091: cmd.arg("--lldb-python").arg("/usr/bin/python3");
1093: cmd.arg("--lldb-python").arg(builder.python());
1109: let lldb_exe = "lldb";
1110: let lldb_version = Command::new(lldb_exe)
1115: if let Some(ref vers) = lldb_version {
1116: cmd.arg("--lldb-version").arg(vers);
1117: let lldb_python_dir = run(Command::new(lldb_exe).arg("-P")).ok();
1118: if let Some(ref dir) = lldb_python_dir {
1119: cmd.arg("--lldb-python-dir").arg(dir);
src/bootstrap/dist.rs
590: run.path("src/lldb_batchmode.py")
631: // lldb debugger scripts
632: builder.install(&builder.src.join("src/etc/rust-lldb"), &sysroot.join("bin"), 0o755);
634: cp_debugger_script("lldb_rust_formatters.py");
896: "llvm-project/lldb",
897: "llvm-project\\lldb",

[Mark-Simulacrum]

Okay, this looks good to me. Let's kick off a try build to make sure at least one dist builder works (@bors try). Presuming that passes and you squash the commits down, r=me.

[mati865]

Looks like bors didn't work.

[Mark-Simulacrum]

I guess I was too fancy. I'll give it its own paragraph?

@bors try

[bors]

⌛ Trying commit d41fd4482c78298c188eab7e71d2b3f8b9b349d0 with merge dd0ed6d6598328dfc60f4bdcd00eacd20db6e3ca...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: dd0ed6d6598328dfc60f4bdcd00eacd20db6e3ca (dd0ed6d6598328dfc60f4bdcd00eacd20db6e3ca)

[RalfJung]

@Mark-Simulacrum do I have to check the logs of that try build or is a pass enough?

[Mark-Simulacrum]

Pass is fine. If you can squash the commits then I think we can land it.

[RalfJung]

Done that.

[Mark-Simulacrum]

@bors r+

Thanks!

[bors]

📌 Commit dc7524b has been approved by Mark-Simulacrum

[Dylan-DPC-zz]

@bors p=1

[bors]

⌛ Testing commit dc7524b with merge 23ffeea...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing 23ffeea to master...

[eddyb]

Uhh, I was using this in order to run (the lldb side of) debuginfo tests. Am I supposed to switch to whatever other lldb I have access to? I recall that not working last time, hence dealing with local builds.

[Mark-Simulacrum]

Hm if that's not working I'm not opposed to restoring this to some extent -- I think it does make sense to drop the dist bits but we can revert the "build" bits.

[eddyb]

Will report back with the results of trying to use NixOS-provided lldb, once I can confirm that compiletest isn't skipping the lldb side of debuginfo tests. Maybe I don't need this at all, but I've relied on it for so long that I doubted I could have it working any other way.

Well, the other reason for the local build was testing the new demangler (see #60705), but I likely can easily build a patched copy of lldb just through NixOS so that isn't as big of a concern.

[eddyb]

Interesting, I've tried lldb 7 through 10 and only 10 actually passed all tests.
I'm not sure if the two tests that lldb 9 still failed on have changed more recently and that's why they fail, but the version requirement likely explains why I recall not getting this to work w/o a local build.

Bonus: src/test/debuginfo/issue-22656.rs passes now (maybe it's just because assertions aren't enabled, heh) so I can remove the hack that deletes it every time I do a build.

[RalfJung]

@eddyb to be clear, you were not using anything dist-related, right? That at looked like long dead code.

[eddyb]

Yeah I was just using the local build, and only for debuginfo tests (lldb = true also enabled lldb debuginfo tests to run even w/o lldb in $PATH, not just built a local copy).

But at least now that I know I can just use lldb 10, it's less trouble to do that.