On 27 October 2017 at 13:23, Sam McCall <sammcc...@google.com> wrote: > On Fri, Oct 27, 2017 at 10:06 PM, Pavel Labath <lab...@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-...@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-...@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
