[lldb-dev] Rust language support question

[Pavel Labath via lldb-dev]

To these very insightful emails from Greg and Jim, I'd just like to
add one request. Please consider the testing strategy of the code you
write early on. One of the problems that we have with these language
plugins (and why we now have a separate thread considering removal of
some of them) is that after the plugin has landed and some time has
elapsed with no activity on it, we have no idea if it is even still
functional without any tests. While you obviously cannot write an
end-to-end test without a rust compiler and runtime libraries around,
plenty of code that you will need to write could be unit-tested
without any dependencies. E.g. if you go down parse "rust dwarf into
clang's astcontext" then the parsing can be tested by feeding it some
dwarf (maybe via llvm/DWARFYAML) and dumping out the resulting AST.

On 27 January 2018 at 02:51, Jim Ingham via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> Jason points out this was gdb writing out a binary form of gdb's psymtabs to be a cheap accelerator table.  Anyway, having the data representation of debug information depend on the internal state of either the compiler or debugger is a fragile thing...
>
> Jim
>
>
>> On Jan 26, 2018, at 6:16 PM, Jim Ingham <jingham at apple.com> wrote:
>>
>> Note, I think the jury's still out on whether it was a great idea to have the swift type representation be the swift compiler's internal state.  It has proven more than a little fragile. I'm not sure I would suggest that route.  I vaguely remember back in the day there was a -g flag in gcc that produced a compiler state dump that gdb was supposed to read.  But IIRC that ended up being more trouble than it was worth.
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev