search for: readerwriteryaml

...0 FILE LOCAL DEFAULT ABS test.c 10: 00000000 0 FILE LOCAL DEFAULT ABS ]] I suggest to remove assert from the RefNameBuilder::buildDuplicateNameMap() method. I think we do not break anything in that case. Any objections, comments, suggestions? [[ --- a/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp +++ b/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp @@ -101,7 +101,6 @@ public: } void buildDuplicateNameMap(const lld::Atom &atom) { - assert(!atom.name().empty()); NameToAtom::iterator pos = _nameMap.find(atom.name()); if (pos != _nameMap.end()) { // Found name col...

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

...-fallthrough -Wcovered-switch-default > -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > -Wstring-conversion -fdiagnostics-color -ffunction-sections > -fdata-sections -O3 -DNDEBUG -fPIC -std=c++14 -MD -MT > > tools/lld/lib/ReaderWriter/YAML/CMakeFiles/lldYAML.dir/ReaderWriterYAML.cpp.o > -MF > > tools/lld/lib/ReaderWriter/YAML/CMakeFiles/lldYAML.dir/ReaderWriterYAML.cpp.o.d > -o > > tools/lld/lib/ReaderWriter/YAML/CMakeFiles/lldYAML.dir/ReaderWriterYAML.cpp.o > -c > > /home/laguest/src/mine-new/llvm/llvm-project/lld/lib/ReaderWriter/YAML/ReaderWri...

...any StringRefs provided by the parse to be used as is). Instead whenever a trait needs to keep a StringRef it must make a copy of the underlying string, and the copies are owned by the generated lld::File object. -------------- next part -------------- A non-text attachment was scrubbed... Name: ReaderWriterYAML.cpp Type: application/octet-stream Size: 42575 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121024/90283f3f/attachment.obj> -------------- next part -------------- -Nick

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. The issues I know of right now are: 1) Should we structure YAML I/O to be a more general I/O utility that could support reading and writing other data formats such as JSON or plists. RIght now, all the code is

Hey Nick, what's the status on YAML IO? The other thread seems to have died. -- Sean Silva

...&n >> bsp;&nb sp; >> >> *Advantages >> *a) Writer has a way to look at the command line options as atoms too. >> b) Not sure if LTO could use this framework to call the compiler back with >> the appropriate set of options. >> c) Can use the ReaderWriterYAML framework for testing! >> >> Thanks >> >> Shankar Easwaran >> ** >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation >> >> > This should be sent to the llvm-dev list. Done. >...

> 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

Hi, I try to build lldb with Cmake (gcc-5.3.0 is necessary for CUDA) on my "SUSE Linux Enterprise Server 12.2 (x86_64)". Unfortunately the build process breaks for lldb with the below mentioned error message. I've downloaded the following packages and configured with the following commands. svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co