search for: yamlparser

...e 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.co...

On Oct 19, 2017 6:50 PM, "Chandler Carruth" <chandlerc at google.com> wrote: On Thu, Oct 19, 2017 at 3:48 AM Sam McCall <sammccall at google.com> wrote: > clangd communicates with an editor via JSON-RPC. It parses JSON with > YAMLParser, which is awkward, and generates JSON with printf and friends, > which is miserable. Much of LLVM does things this way, but clangd does it a > lot. > > I'd like to try replacing this with a JSON library. nlohmann/json[1] seems > like a reasonable fit: C++11 with exceptions option...

clangd communicates with an editor via JSON-RPC. It parses JSON with YAMLParser, which is awkward, and generates JSON with printf and friends, which is miserable. Much of LLVM does things this way, but clangd does it a lot. I'd like to try replacing this with a JSON library. nlohmann/json[1] seems like a reasonable fit: C++11 with exceptions optional, simple build, MIT li...

I've been working on reading and writing yaml encoded documents for the lld project. Michael Spencer added the YAMLParser.h functionality to llvm/Support to help in parsing yaml documents. That parser greatly helps at the syntax level, but you still need to hand write a lot of semantic checking and then convert the various node types in to something usable. I've developed a layer on top of YAMLParser.h I'm...

...e be considered an error? I think it is fine not to treat it as an error because there can be legitimate use cases of unterminated [[, for example, [[ in a string literal. YAML parsing is complex. I don't expect the preprocessor to be smart enough to recognize string literals. (llvm/lib/Support/YAMLParser.cpp does not seem to provide raw strings of spaces and comments. Hooking a preprocessor into the scanner does not seem to be simple.) Do people know other preprocessing features which may be useful?

...m/Object/ObjectFile.h (working copy) > + content_iterator& operator++() { > + error_code ec; > + return this->increment (ec); > + } > > This is wrong. It ignores the error. operator ++ should be implemented > the same way as ++ is in include/llvm/Support/YAMLParser.h. If > iteration fails, turn the iterator into an end iterator and set a > failed flag and allow the user to access the error_code. > > - Michael Spencer > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http...

...bjectFile.h (revision 158307) +++ include/llvm/Object/ObjectFile.h (working copy) + content_iterator& operator++() { + error_code ec; + return this->increment (ec); + } This is wrong. It ignores the error. operator ++ should be implemented the same way as ++ is in include/llvm/Support/YAMLParser.h. If iteration fails, turn the iterator into an end iterator and set a failed flag and allow the user to access the error_code. - Michael Spencer

...ated 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...

...e be considered an error? I think it is fine not to treat it as an error because there can be legitimate use cases of unterminated [[, for example, [[ in a string literal. YAML parsing is complex. I don't expect the preprocessor to be smart enough to recognize string literals. (llvm/lib/Support/YAMLParser.cpp does not seem to provide raw strings of spaces and comments. Hooking a preprocessor into the scanner does not seem to be simple.) Do people know other preprocessing features which may be useful? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ll...

.... The core of the problem is when a new document is started, we don't know what kind of file it is going to be, to know what keys are legal. I first looked into used tags to specify the document type. For example: --- !archive members: - name: bar.o # more stuff But after modifying YAMLParser to make that the tag available, then trying to figure out how to make the tag actionable in the trait, I realized that for maps, the tag is just like another key. So, if every client agreed that the first key/value was a particular key name (e.g. tag: type) which YAML I/O already supports, then t...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...is started, we don't > know what kind of file it is going to be, to know what keys are legal. > I first looked into used tags to specify the document type. For > example: > > --- !archive > members: > - name: bar.o > # more stuff > > But after modifying YAMLParser to make that the tag available, then > trying to figure out how to make the tag actionable in the trait, I > realized that for maps, the tag is just like another key. So, if > every client agreed that the first key/value was a particular key name > (e.g. tag: type) which YAML I/O...

So, I'm trying to use this file to look inside COFF files. Got the header. OK. Now I want to look at the sections. Look, there's a section iterator. I can use that! So, I write: for (llvm::object::section_iterator iter = Obj.begin_sections (); iter != Obj.end_sections(); ++iter ) and it doesn't compile. There's no ++ for section iterators. Apparently, you're supposed to

...> 0. Program arguments: ~/llvm/Debug+Asserts/bin/yaml2obj -format=coff > t.yaml > > Hopefully a fuzzer that is fuzzing a yaml input would not waste its time with syntactically invalid or unusual YAML. Also, you're thinking of YAMLIO which is a layer on top of the YAML parser (YAMLParser.{h,cpp}). It might make sense to not use YAMLIO (it is good for some types of data, not for all) but still use the YAML parser. -- Sean Silva > On Tue, Apr 28, 2015 at 2:00 PM, Alex L <arphaman at gmail.com> wrote: > >> >> >> 2015-04-28 10:14 GMT-07:00 Quentin Colom...

...le.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h > YAMLParser.h > YAMLTraits.h > > > So, as a very crude first attempt, you call the first group of stuff > "Base", the second group "Support", and add a dependency from Support to > Base. This has nothing to do with tablegen, btw, and tablegen would still > probably dep...

...le.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h > YAMLParser.h > YAMLTraits.h > YAML Parser as well. -- Mehdi > > > So, as a very crude first attempt, you call the first group of stuff > "Base", the second group "Support", and add a dependency from Support to > Base. This has nothing to do with tablegen, btw,...

...ir/TargetParser.cpp.o CMakeFiles/LLVMSupport.dir/ThreadPool.cpp.o CMakeFiles/LLVMSupport.dir/Timer.cpp.o CMakeFiles/LLVMSupport.dir/ToolOutputFile.cpp.o CMakeFiles/LLVMSupport.dir/Triple.cpp.o CMakeFiles/LLVMSupport.dir/Twine.cpp.o CMakeFiles/LLVMSupport.dir/Unicode.cpp.o CMakeFiles/LLVMSupport.dir/YAMLParser.cpp.o CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o CMakeFiles/LLVMSupport.dir/raw_ostream.cpp.o CMakeFiles/LLVMSupport.dir/regcomp.c.o CMakeFiles/LLVMSupport.dir/regerror.c.o CMakeFiles/LLVMSupport.dir/regexec.c.o CMakeFiles/LLVMSupport.dir/regfree.c.o...

> To better understand how a client would use YAML I/O. I've completely rewritten the ReaderYAML and WriterYAML in lld to use YAML I/O. The source code is now about half the size. But more importantly, the error checking is much, much better and any time an attribute (e.g. of an Atom) is changed or added, there is just one place to update the yaml code instead of two places (the reader

On Oct 22, 2012, at 5:07 PM, Nick Kledzik wrote: > On Oct 22, 2012, at 4:40 PM, Sean Silva wrote: >> Hey Nick, what's the status on YAML IO? The other thread seems to have died. > > I'm waiting on Michael Spencer's feedback. To better understand how a client would use YAML I/O. I've completely rewritten the ReaderYAML and WriterYAML in lld to use YAML I/O. The

...we don't know what kind of file it is going to be, to know what keys are legal. I first looked into used tags to specify the document type. For example: >> >> --- !archive >> members: >> - name: bar.o >> # more stuff >> >> But after modifying YAMLParser to make that the tag available, then trying to figure out how to make the tag actionable in the trait, I realized that for maps, the tag is just like another key. So, if every client agreed that the first key/value was a particular key name (e.g. tag: type) which YAML I/O already supports, then t...