[lldb-dev] Rust support in LLDB, again

[Pavel Labath via lldb-dev]

+1 to everything that Jonas said.

On 30/09/2019 18:28, Jonas Devlieghere via lldb-dev wrote:
> Hi Vadim,
> 
> On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>>
>> Hi,
>> Last year there was an effort led by Tom Tromey to add Rust language support into LLDB.  He had implemented a fairly complete language plugin, however it was not accepted into mainline because of supportability concerns.    I guess these concerns had some merit, because this change did not survive even in Rust's private branch due to the difficulty of rebasing on top of LLVM 9.
> 
> Unless my memory is failing me, I don't think we ever explicitly
> rejected Rust's language plugin. We removed a few other language
> plugins (Go, Java) that were not maintained and were becoming an
> increasing burden on the community. At the same time we agreed that we
> didn't want to make the same mistake again. Some of the things that
> come to mind are having a working implementation, testing, CI, etc. If
> the rust community can show that they're dedicated to maintaining Rust
> support in LLDB, I wouldn't expect a lot of resistance. I just bring
> this up because I don't want to discourage anyone from adding support
> for new languages to LLDB.
> 
>> I am wondering if there's a more limited version of this, that can be merged into mainline:
>> In terms of its memory model, Rust is not that far off from C++, so treating Rust types is if they were C++ types basically works.  There is only one major problem: currently LLDB cannot deal with tagged unions, which Rust code uses quite heavily.   When such a type is encountered, LLDB just emits an empty struct, which makes it impossible to examine the contents.
>>
>> My tentative proposal is to modify LLDB's DWARFASTParserClang to handle DW_TAG_variant et al, and create a C++ approximation of these types, e.g. as a polymorphic class, or just an untagged union.   This would provide at least a minimal level of functionality for Rust (and possibly other languages) and be a much lesser maintenance burden on LLDB core team.
>> What would y'all say?
> 
> The people that actually work on this code should answer this, but
> personally I don't have strong objections to this. That said, of
> course I would prefer to have a (maintained) language plugin instead.
> 
> PS: Are there other changes that live downstream that are not Rust
> specific and would benefit upstream LLDB and would potentially improve
> Rust debugging?
> 
> Jonas