Hi. I'm working on adding Rust language support to lldb.
One question that's come up is the best way to handle expression
parsing.
On the one hand, it would be convenient to reuse an existing parser --
the one that we discussed was the "syn" crate. But, this is a Rust
program.
So then there's
> On Jan 26, 2018, at 2:54 PM, Tom Tromey via lldb-dev
> wrote:
>
> Hi. I'm working on adding Rust language support to lldb.
>
> One question that's come up is the best way to handle expression
> parsing.
>
> On the one hand, it would be convenient to reuse an existing parser --
> the one th
I second Greg, we don't really want to make the lldb_private namespace into
API. We don't have any intention to stabilize this, and the interfaces expose
a lot of clang & llvm types which are also not stable and change not
infrequently. So in effect your plugin would end up being rev-locked to
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
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
> "Jim" == Jim Ingham writes:
Jim> I naively thought this would make support for Rust weak, but folks
Jim> on Stack Overflow say it actually works pretty well for viewing
Jim> variables (using "frame var" or lldb's ValueObject's). Stepping
Jim> and so forth apparently seemed to be working ok
> "Pavel" == Pavel Labath writes:
Pavel> To these very insightful emails from Greg and Jim, I'd just like to
Pavel> add one request. Please consider the testing strategy of the code you
Pavel> write early on. One of the problems that we have with these language
Pavel> plugins (and why we now
On 29 January 2018 at 18:39, Tom Tromey wrote:
>> "Pavel" == Pavel Labath writes:
>
> Pavel> To these very insightful emails from Greg and Jim, I'd just like to
> Pavel> add one request. Please consider the testing strategy of the code you
> Pavel> write early on. One of the problems that we
> "Pavel" == Pavel Labath writes:
Pavel> Yes, but it still adds another manual step to the setup process, which
Pavel> means most developers will not do it. It also exposes us to a
Pavel> non-determinism coming from different versions of the rust compiler
Pavel> people will have.
I see what
