<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Unless my memory is failing me, I don't think we ever explicitly<br>
> rejected Rust's language plugin. We removed a few other language<br>
> plugins (Go, Java) that were not maintained and were becoming an<br>
> increasing burden on the community. At the same time we agreed that we<br>
> didn't want to make the same mistake again. Some of the things that<br>
> come to mind are having a working implementation, testing, CI, etc. If<br>
> the rust community can show that they're dedicated to maintaining Rust<br>
> support in LLDB, I wouldn't expect a lot of resistance. I just bring<br>
> this up because I don't want to discourage anyone from adding support<br>
> for new languages to LLDB.<br></blockquote><div><br></div><div>Do you have any thoughts on how this support should look like?<br></div><div><br></div><div></div><div>Realistically, though, I would expect this to go about as well as the previous two attempts you've mentioned. :(  <br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> 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.<br></blockquote><div><br></div><div><div>I looked at the code in more detail, and unfortunately it looks like C++ AST is not flexible enough to represent variants as polymorphic classes, so It'll have to be just untagged unions.   But I'd love to hear otherwise from people more familiar with that code.<br></div></div><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> PS: Are there other changes that live downstream that are not Rust<br>
> specific and would benefit upstream LLDB and would potentially improve<br>
> Rust debugging?<br></blockquote><div><br></div><div>Nothing major I can think of.  The rest of changes seem to be pretty Rust-specific.<br></div><div><br></div><div>My general feedback is that it would help a lot if LLDB were less C++- (and in particular clang-) centric.  For example, right now LLDB converts various debug info formats directly into clang AST.  As a result, other languages are forced to re-implement debug info parsing from scratch and soon as they need to customize anything that cannot be mapped to C/C++ concepts.   There probably needs to be some sort of language-agnostic layer that abstracts debug info formats for use by language plugins.  If this layer supported DWARF spec in its entirety, I expect that most languages would need little to no customization, at least until you get to implementing a REPL for that language.</div><div><br></div><div>A stable ABI for dynamically-loadable language plugins would be the best, of course.<br></div><br></div></div>