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@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 <jing...@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
