summaryrefslogtreecommitdiff
path: root/llvm/unittests/Bitcode/BitstreamReaderTest.cpp
AgeCommit message (Collapse)Author
2019-07-03[Bitcode] Move Bitstream to a separate libraryFrancis Visoiu Mistrih
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091
2019-06-26BitStream reader: propagate errorsJF Bastien
The bitstream reader handles errors poorly. This has two effects: * Bugs in file handling (especially modules) manifest as an "unexpected end of file" crash * Users of clang as a library end up aborting because the code unconditionally calls `report_fatal_error` The bitstream reader should be more resilient and return Expected / Error as soon as an error is encountered, not way late like it does now. This patch starts doing so and adopting the error handling where I think it makes sense. There's plenty more to do: this patch propagates errors to be minimally useful, and follow-ups will propagate them further and improve diagnostics. https://bugs.llvm.org/show_bug.cgi?id=42311 <rdar://problem/33159405> Differential Revision: https://reviews.llvm.org/D63518 llvm-svn: 364464
2019-01-20Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2017-06-06Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth
clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
2017-01-04Reapply "Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie
IntrusiveRefCntPtr"" If this is a problem for anyone (shared_ptr is two pointers in size, whereas IntrusiveRefCntPtr is 1 - and the ref count control block that make_shared adds is probably larger than the one int in RefCountedBase) I'd prefer to address this by adding a lower-overhead version of shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing) to avoid the intrusiveness - this allows memory ownership to remain orthogonal to types and at least to me, seems to make code easier to understand (since no implicit ownership acquisition can happen). This recommits 291006, reverted in r291007. llvm-svn: 291016
2017-01-04Revert "Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie
IntrusiveRefCntPtr" Breaks Clang's use of bitcode. Reverting until I have a fix to go with it there. This reverts commit r291006. llvm-svn: 291007
2017-01-04Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie
IntrusiveRefCntPtr If this is a problem for anyone (shared_ptr is two pointers in size, whereas IntrusiveRefCntPtr is 1 - and the ref count control block that make_shared adds is probably larger than the one int in RefCountedBase) I'd prefer to address this by adding a lower-overhead version of shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing) to avoid the intrusiveness - this allows memory ownership to remain orthogonal to types and at least to me, seems to make code easier to understand (since no implicit ownership acquisition can happen). llvm-svn: 291006
2016-11-08Bitcode: Decouple block info block state from reader.Peter Collingbourne
As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html Move block info block state to a new class, BitstreamBlockInfo. Clients may set the block info for a particular cursor with the BitstreamCursor::setBlockInfo() method. At this point BitstreamReader is not much more than a container for an ArrayRef<uint8_t>, so remove it and replace all uses with direct uses of memory buffers. Differential Revision: https://reviews.llvm.org/D26259 llvm-svn: 286207
2016-11-02Bitcode: Fix short read implementation.Peter Collingbourne
We need to zero extend the byte in order to correctly shift it into a 64-bit value. llvm-svn: 285785
2016-11-02Bitcode: Change reader interface to take memory buffers.Peter Collingbourne
As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html This change also fixes an API oddity where BitstreamCursor::Read() would return zero for the first read past the end of the bitstream, but would report_fatal_error for subsequent reads. Now we always report_fatal_error for all reads past the end. Updated clients to check for the end of the bitstream before reading from it. I also needed to add padding to the invalid bitcode tests in test/Bitcode/. This is because the streaming interface was not checking that the file size is a multiple of 4. Differential Revision: https://reviews.llvm.org/D26219 llvm-svn: 285773
2016-03-28Explicitly test BitstreamReader::setArtificialByteLimit, NFCDuncan P. N. Exon Smith
Explicitly check that artificial byte limit is rounded correctly by exposing BitstreamReader::Size through a new accessor, getSizeIfKnown. The original code for rounding (from r264547) wasn't obviously correct, and even though r264623 cleaned it up (by calling llvm::alignTo) I think it's worth testing. llvm-svn: 264650
2016-03-28Remove accidentally duplicated testDuncan P. N. Exon Smith
This was identical to setArtificialByteLimitNotWordBoundary. llvm-svn: 264646
2016-03-27Bitcode: Fix MSVC bot failure from r264549Duncan P. N. Exon Smith
make_unique => llvm::make_unique llvm-svn: 264553
2016-03-27Support: Implement StreamingMemoryObject::getPointerDuncan P. N. Exon Smith
The implementation is fairly obvious. This is preparation for using some blobs in bitcode. For clarity (and perhaps future-proofing?), I moved the call to JumpToBit in BitstreamCursor::readRecord ahead of calling MemoryObject::getPointer, since JumpToBit can theoretically (a) read bytes, which (b) invalidates the blob pointer. This isn't strictly necessary the two memory objects we have: - The return of RawMemoryObject::getPointer is valid until the memory object is destroyed. - StreamingMemoryObject::getPointer is valid until the next chunk is read from the stream. Since the JumpToBit call is only going ahead to a word boundary, we'll never load another chunk. However, reordering makes it clear by inspection that the blob returned by BitstreamCursor::readRecord will be valid. I added some tests for StreamingMemoryObject::getPointer and BitstreamCursor::readRecord. llvm-svn: 264549
2016-03-27Bitcode: Add SimpleBitstreamCursor::setArtificialByteLimitDuncan P. N. Exon Smith
Allow users of SimpleBitstreamCursor to limit the number of bytes available to the cursor. This is preparation for instantiating a cursor that isn't allowed to load more bytes from a StreamingMemoryObject (just move around the ones already-loaded). llvm-svn: 264547
2016-03-27Bitcode: Add SimpleBitstreamCursor::getPointerToByte, etc.Duncan P. N. Exon Smith
Add API to SimpleBitstreamCursor to allow users to translate between byte addresses and pointers. - jumpToPointer: move the bit position to a particular pointer. - getPointerToByte: get the pointer for a particular byte. - getPointerToBit: get the pointer for the byte of the current bit. - getCurrentByteNo: convenience function for assertions and tests. Mainly adds unit tests (getPointerToBit/Byte already has a use), but also preparation for eventually using jumpToPointer. llvm-svn: 264546
2014-11-13[Bitcode] AtEndOfStream should only check against the size if it's known.Jordan Rose
This avoids an issue where AtEndOfStream mistakenly returns true at the /start/ of a stream. (In the rare case that the size is known and actually 0, the slow path will still handle it correctly.) llvm-svn: 221840