[lldb-dev] [llvm-dev] RFC: Adding a JSON library to LLVM Support
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Fri Oct 27 14:01:02 PDT 2017
On 27 October 2017 at 13:23, Sam McCall <sammccall at google.com> wrote:
> On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath <labath at google.com> wrote:
>>
>> LLDB has a JSON parser/serializer that we'd like to get rid of.
>
> Ah, sorry for missing that!
> What makes you want to get rid of it? Maintenance/duplication, or things you
> don't like about using it?
> Do you see it as a suitable thing to "promote" up to Support for wider use,
> instead?
I don't think the json library in lldb is in a shape that can be
easily promoted to llvm/Support (see previous attempt here
<https://reviews.llvm.org/D24369>). I think you'd be better off
writing a new one from scratch (or reusing parts of YamlIO).
>
>>
>> The
>> main thing that's missing from YamlIO for us to do that is the ability
>> to handle (or at very least, not choke on) unknown keys (for example,
>> keys that are only generated by an lldb-server from the future --
>> backwards/forwards compatibility).
>
> Interesting - that certainly sounds doable (not knowing the details).
> You'd still need a way to serialize though?
For the lldb <-> lldb-server communication, the ability to ignore the
parts of the message we don't understand would be enough, but I do not
fully understand all the different ways in which it is used. However,
I think that at least in some cases we have a field in a json object,
which is completely opaque to us, but we are expected to take it, and
pass it on to someone. I'm looping in lldb-dev, hopefully someone can
elaborate on the requirements.
>
>>
>> On 27 October 2017 at 12:53, Sam McCall via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > We don't have a dedicated JSON library in the LLVM tree, I'd like to add
>> > one. The pressing need is for clangd, but we have other tools that
>> > read/write JSON too.
>> >
>> > I'm proposing we write a new one, rather than importing a third-party
>> > library (licensing/integration reasons), on or extending
>> > YamlParser/YamlIO
>> > (usability/flexibility). I lean towards a design that parses a full DOM
>> > at
>> > once, and provides literal-like syntax for composing documents.
>> >
>> > I've written a document laying out the reasons for taking this path, and
>> > my
>> > proposal for a design (with links to a prototype)
>> >
>> > https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
>> > (Comments are enabled, but high-level discussion probably belongs on the
>> > list instead.)
>> >
>> > What do you think? I'm particularly interested in which parts of LLVM
>> > produce/consume JSON (or might want to), and what they need. I'm mostly
>> > familiar with the stuff in clang-tools-extra.
>> >
>> > Cheers, Sam
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>
>
More information about the lldb-dev
mailing list