jryans added a comment. In D149213#4491889 <https://reviews.llvm.org/D149213#4491889>, @VladimirMakaev wrote:
> I think there was an attempt in the past to build TypeSystemRust. Rust > Project had a fork of LLDB with this implemented by Tom Tromey and CodeLLDB > maintainer(vadimcn) has one. Both of them were not able to merge that into > LLDB codebase. A relevant link to a discussion > https://rust-lang.zulipchat.com/#narrow/stream/317568-t-compiler.2Fwg-debugging/topic/upstreaming.20rust.20support.20into.20lldb > > Apart from just implementing type system itself (which is much bigger scope > than this change) there are other non-trivial issues: > > 1. There is no "compiler-as-a-service" in Rust so getting expressions to work > is non-trivial. An interpreter of some sort needs to be built with subset of > Rust support > 2. Infra changes (DEVOPS) changes are required to start building Rust > inferiors to run tests on CI > 3. LLVM / rustc cross repository logistics. Rustc probably needs to live in > LLVM to make this work well. I know this is not exactly the focus of this patch, but I just wanted to reply to this portion (since you've mentioned it). While some people did try to suggest things like your points 2 and 3 in previous Rust support attempts, I would say it seems impractical to require pulling a whole language implementation into LLVM just to add debugging support. If LLDB really wants to be a many-language debugger, I would strongly urge looking for testing solutions that do not require somehow adding an full implementation of each one into the tree. After all, the whole point of debug info formats like DWARF is that the producer and consumer do not need to be tightly coupled (since there's a standard format in between). I would argue a more practical approach would involve test cases based on whatever IR or AST might be appropriate for the feature under test, e.g. DWARF output from Rust, Rust IR or MIR, etc. These things are just data, and LLDB (and / or small helper tools) could process this data without the need for an entire language implementation. A discussion from 2019 (https://discourse.llvm.org/t/rust-support-in-lldb-again/53210) seemed to potentially be open to such an idea, but perhaps it's worth starting a new discussion thread focused on the testing requirements for language support in LLDB which attempts to work out guidelines which allow for languages whose implementations live outside of the LLVM tree. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149213/new/ https://reviews.llvm.org/D149213 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
