<div dir="ltr"><div>Hi Greg,</div><div><br></div><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"><div><div>So if Rust doesn't use clang in its compiler</div><div>- create a new TypeSystem for Rust that would convert DWARF into Rust AST types that are native to your Rust compiler that uses as much of the Rust compiler sources as possible</div><div>- write a native Rust expression parser which hopefully uses your Rust compiler sources to evaluate and run your expression</div></div></blockquote><div><br></div><div>This already exists, but is proving difficult to maintain out-of-tree.  (I wish that people who modify plugin-related APIs would spend a few minutes documenting what each of those methods is supposed to do, so plugin maintainers wouldn't need to reverse-engineer this info!  /rant).<br></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"><div><div></div><div>So the right answer depends on what the Rust community wants. Is the language changing rapidly where the debugger must be in sync to take advantage and use the latest language features? Or is it stable?</div></div></blockquote><div><br></div><div>Debug info is mostly stable, but over time there will be changes, of course.  For example, at some point we'll want to change the symbol mangling scheme.<br></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"><div><div></div><div>The other nice things about creating a new TypeSystem, is that it is a plugin and you don't need to compile it in. cmake can be taught to conditionally compile in your type system if you want it. It would also allow you to have more than one Rust type system if needed for different Rust language versions that each could be exclusively compiled in. Having your sources be in a new TypeSystem plug-in ensure easy merging when it comes to different repositories.</div></div></blockquote><div><br></div><div>Understood.  I just want to point out that implementing a complete type system plugin just to support one or two type kinds incompatible with C++ is a pretty big burden on language implementors.   If LLDB had a default "type system" geared towards representing types expressible in DWARF, not just those found in the C family, it would be usable with other languages without any custom work, at least until one starts getting into fancy features like REPL.  <br></div><div>It might also serve as an abstraction layer for supporting different debug info formats.  As I understand, right now, in order to support MS PDB, we'd need to implement a custom parser for it in addition to the DWARF one?<br></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"><div><div>Let us know about which approach sounds better to the Rust community and we can proceed from there!</div></div></blockquote><div><br></div><div>I guess we'd prefer to upstream the Rust plugin.   But I'm not sure how keep it from breaking without requiring all LLVM devs to install a Rust compiler...<br></div><div><br></div></div></div>