[Lldb-commits] [PATCH] D149213: [lldb] Add basic support for Rust enums in TypeSystemClang

[Jim Ingham via lldb-commits]

> On Jul 21, 2023, at 9:52 AM, J. Ryan Stinnett via Phabricator via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> 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.
> 

From our experience supporting other languages, It is not enough to write tests that check static predicates.  You need to run expressions and move the program around to test the expression parser, and runtime introspection features, etc.  Imagine trying to write tests for stepping through Rust async dispatch w/o being able to run programs in the test suite...  

A sustainable language plugin is going to need those sorts of tests, and trying to write those tests w/o a compiler to build the test subjects will get really tedious very quickly.  So whatever people plan to do, you need to make it more testable than just "did I get the DWARF right".

IMO to make a supportable Rust plugin that wider testing has to go on in CI somewhere.  Note, that doesn't require a full copy of the Rust compiler in the llvm sources.   As Greg pointed out in that thread you mentioned, you can back the TypeSystemRust and the ExpressionParserRust with whatever implementation suits you, and if you can do that in a simpler way that doesn't involve the actual language implementation, that's fine.  

But I do think there needs to be bots & testing for the plugins that can rely on being able to build & test more complex scenarios than just what you can get from static analysis. Otherwise, all the people working on support for other languages are going to keep breaking the Rust implementation, which won't make for a productive community.

Jim

> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D149213/new/
> 
> https://reviews.llvm.org/D149213
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits