summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
* [unittest] Fix unittests/Support/Path.cpp after D49466Fangrui Song2019-11-261-6/+12
|
* Initial implementation of -fmacro-prefix-map and -ffile-prefix-mapDan McGregor2019-11-261-0/+29
| | | | | | | | | GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro. -ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map Reviewed By: rnk, Lekensteyn, maskray Differential Revision: https://reviews.llvm.org/D49466
* Reland 9f3fdb0d7fab: [Driver] Use VFS to check if sanitizer blacklists existIlya Biryukov2019-11-211-2/+4
| | | | | | | With updates to various LLVM tools that use SpecialCastList. It was tempting to use RealFileSystem as the default, but that makes it too easy to accidentally forget passing VFS in clang code.
* Fix uninitialized variable warning. NFC.Simon Pilgrim2019-11-181-2/+1
|
* [Support] Optimize SHA1 implementationNick Terrell2019-11-111-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add inline to the helper functions because gcc-9 won't inline all of them without the hint. I've avoided `__attribute__((always_inline))` because gcc and clang will inline without it, and improves compatibility. * Replace the byte-by-byte copy in update() with endian::readbe32() since perf reports that 1/2 of the time is spent copying into the buffer before this patch. When lld uses --build-id=sha1 it spends 30-45% of CPU in SHA1 depending on the binary (not wall-time since it is parallel). This patch speeds up SHA1 by a factor of 2 on clang-8 and 3 on gcc-6. This leads to a >10% improvement in overall linking time. lld-speed-test benchmarks run on an Intel i9-9900k with Turbo disabled on CPU 0 compiled with clang-9. Stats recorded with `perf stat -r 5`. All inputs are using `--build-id=sha1`. | Input | Before (seconds) | After (seconds) | | --- | --- | --- | | chrome | 2.14 | 1.82 (-15%) | | chrome-icf | 2.56 | 2.29 (-10%) | | clang | 0.65 | 0.53 (-18%) | | clang-fsds | 0.69 | 0.58 (-16%) | | clang-gdb-index | 21.71 | 19.3 (-11%) | | gold | 0.42 | 0.34 (-19%) | | gold-fsds | 0.431 | 0.355 (-17%) | | linux-kernel | 0.625 | 0.575 (-8%) | | llvm-as | 0.045 | 0.039 (-14%) | | llvm-as-fsds | 0.035 | 0.039 (-11%) | | mozilla | 11.3 | 9.8 (-13%) | | mozilla-gc | 11.84 | 10.36 (-12%) | | mozilla-O0 | 8.2 | 5.84 (-28%) | | scylla | 5.59 | 4.52 (-19%) | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69295
* Fix null dereference in yaml::Document::skipThomas Finch2019-11-111-0/+11
| | | | | | | | | | | | | | | | Summary: The attached test case replicates a null dereference crash in `yaml::Document::skip()`. This was fixed by adding a check and early return in the method. Reviewers: Bigcheese, hintonda, beanz Reviewed By: hintonda Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69974
* [Support] Add erase() to json::ObjectSam McCall2019-11-111-5/+32
|
* [CommandLine] Add inline ArgName printingDon Hinton2019-11-061-0/+50
| | | | | | | | | | | | | | | | | | | | | Summary: This patch adds PrintArgInline (after PrintArg) that strips the leading spaces from an argument before printing them, for usage inline. Related bug: PR42943 <https://bugs.llvm.org/show_bug.cgi?id=42943> Patch by Daan Sprenkels! Reviewers: jhenderson, chandlerc, hintonda Reviewed By: jhenderson Subscribers: hiraditya, kristina, llvm-commits, dsprenkels Tags: #llvm Differential Revision: https://reviews.llvm.org/D69501
* YAML parser robustness improvementsThomas Finch2019-11-051-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of bugs found in the YAML parser through fuzzing. In general, this makes the parser more robust against malformed inputs. The fixes are mostly improved null checking and returning errors in more cases. In some cases, asserts were changed to regular errors, this provides the same robustness but also protects release builds from the triggering conditions. This also improves the fuzzability of the YAML parser since asserts can act as a roadblock to further fuzzing once they're hit. Each fix has a corresponding test case: - TestAnchorMapError - Added proper null pointer handling in `Stream::printError` if N is null and `KeyValueNode::getValue` if getKey returns null, `Input::createHNodes` `dyn_casts` changed to `dyn_cast_or_null` so the null pointer checks are actually able to fail - TestFlowSequenceTokenErrors - Added case in `Document::parseBlockNode` for FlowMappingEnd, FlowSequenceEnd, or FlowEntry tokens outside of mappings or sequences - TestDirectiveMappingNoValue - Changed assert to regular error return in `Scanner::scanValue` - TestUnescapeInfiniteLoop - Fixed infinite loop in `ScalarNode::unescapeDoubleQuoted` by returning an error for unrecognized escape codes - TestScannerUnexpectedCharacter - Changed asserts to regular error returns in `Scanner::consume` - TestUnknownDirective - For both of the inputs the stream doesn't fail and correctly returns TK_Error, but there is no valid root node for the document. There's no reasonable way to make the scanner fail for unknown directives without breaking the YAML spec (see spec-07-01.test). I think the assert is unnecessary given that an error is still generated for this case. The `SimpleKeys.clear()` line fixes a bug found by AddressSanitizer triggered by multiple test cases - when TokenQueue is cleared SimpleKeys is still holding dangling pointers into it, so SimpleKeys should be cleared as well. Patch by Thomas Finch! Reviewers: chandlerc, Bigcheese, hintonda Reviewed By: Bigcheese, hintonda Subscribers: hintonda, kristina, beanz, dexonsmith, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61608
* TargetParserTest - testARMArch - stop bitwise operators on boolean warnings. ↵Simon Pilgrim2019-11-021-4/+5
| | | | | | NFCI. Ensure the test still runs all target checks but stop the static analyzer warnings.
* [clang][llvm] Obsolete Exynos M1 and M2Evandro Menezes2019-10-302-33/+11
|
* [ObjectYAML] - Redefine LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::yaml::Hex*) as ↵Georgii Rymar2019-10-301-7/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | LLVM_YAML_IS_FLOW_SEQUENCE_VECTOR. I am using it in https://reviews.llvm.org/D69399. This change changes how obj2yaml dumps arrays of `llvm::yaml::Hex8/llvm::yaml::Hex16/llvm::yaml::Hex32` from: ``` PayloadBytes: - 0x01 - 0x02 ... ``` To ``` PayloadBytes: [ 0x01, 0x02, ... ] ``` The latter way is shorter and looks better for arrays. Differential revision: https://reviews.llvm.org/D69558
* [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmapNick Terrell2019-10-291-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a flag `F_no_mmap` to `FileOutputBuffer` to support `--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores this flag for compatibility with GNU ld and gold. We need this flag to speed up link time for large binaries in certain scenarios. When we link some of our larger binaries we find that LLD takes 50+ GB of memory, which causes memory pressure. The memory pressure causes the VM to flush dirty pages of the output file to disk. This is normally okay, since we should be flushing cold pages. However, when using BtrFS with compression we need to write 128KB at a time when we flush a page. If any page in that 128KB block is written again, then it must be flushed a second time, and so on. Since LLD doesn't write sequentially this causes write amplification. The same 128KB block will end up being flushed multiple times, causing the linker to many times more IO than necessary. We've observed 3-5x faster builds with -no-mmap-output-file when we hit this scenario. The bad scenario only applies to compressed filesystems, which group together multiple pages into a single compressed block. I've tested BtrFS, but the problem will be present for any compressed filesystem on Linux, since it is caused by the VM. Silently ignoring --no-mmap-output-file caused a silent regression when we switched from gold to lld. We pass --no-mmap-output-file to fix this edge case, but since lld silently ignored the flag we didn't realize it wasn't being respected. Benchmark building a 9 GB binary that exposes this edge case. I linked 3 times with --mmap-output-file and 3 times with --no-mmap-output-file and took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM, BtrFS mounted with -compress-force=zstd, and an 80% full disk. | Mode | Time | |---------|-------| | mmap | 894 s | | no mmap | 126 s | When compression is disabled, BtrFS performs just as well with and without mmap on this benchmark. I was unable to reproduce the regression with any binaries in lld-speed-test. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69294
* Fix https://bugs.llvm.org/show_bug.cgi?id=43791Guillaume Chatelet2019-10-281-1/+1
|
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-242-55/+0
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-231-0/+54
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-231-54/+0
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-231-0/+54
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Fix llvm signal tests build.David Carlier2019-10-211-0/+1
| | | | llvm-svn: 375406
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-182-0/+54
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* [Error] Make llvm::cantFail include the original error messagesDon Hinton2019-10-171-7/+10
| | | | | | | | | | | | | | | | Summary: The current implementation eats the current errors and just outputs the message parameter passed to llvm::cantFail. This change appends the original error message(s), so the user can see exactly why cantFail failed. New logic is conditional on NDEBUG. Reviewed By: lhames Tags: #llvm Differential Revision: https://reviews.llvm.org/D69057 llvm-svn: 375176
* Reapply r375051: [support] GlobPattern: add support for `\` and `[!...]`, ↵Jordan Rupprecht2019-10-171-38/+96
| | | | | | | | | | | | | | | | | | | | | | | | and allow `]` in more places Reland r375051 (reverted in r375052) after fixing lld tests on Windows in r375126 and r375131. Original description: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 llvm-svn: 375149
* Revert [support] GlobPattern: add support for `\` and `[!...]`, and allow ↵Jordan Rupprecht2019-10-161-96/+38
| | | | | | | | | | `]` in more places This reverts r375051 (git commit a409afaad64ce83ea44cc30ee5f96b6e613a6e98) The patch does not work on Windows due to `\` in filenames being interpreted as escaping rather than literal path separators when used by lld linker scripts. llvm-svn: 375052
* [support] GlobPattern: add support for `\` and `[!...]`, and allow `]` in ↵Jordan Rupprecht2019-10-161-38/+96
| | | | | | | | | | | | | | | | | | | | | | | | more places Summary: Update GlobPattern in libSupport to handle a few more cases. It does not fully match the `fnmatch` used by GNU objcopy since named character classes (e.g. `[[:digit:]]`) are not supported, but this should support most existing use cases (mostly just `*` is what's used anyway). This will be used to implement the `--wildcard` flag in llvm-objcopy to be more compatible with GNU objcopy. This is split off of D66613 to land the libSupport changes separately. The llvm-objcopy part will land soon. Reviewers: jhenderson, MaskRay, evgeny777, espindola, alexshap Reviewed By: MaskRay Subscribers: nickdesaulniers, emaste, arichardson, hiraditya, jakehehrlich, abrachet, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66613 undo objcopy changes to make this libsupport only llvm-svn: 375051
* Fix an unused variable introduced in rL374955 / rG21703543.David L. Jones2019-10-161-0/+1
| | | | | | Even though this is a unit test, it still may be run under optimization. llvm-svn: 374961
* [Reland][VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-4/+171
| | | | | | | | | | | | | | | | | | | | RedirectingFS Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374955
* Revert "[VirtualFileSystem] Support virtual working directory in the ↵Jonas Devlieghere2019-10-151-171/+4
| | | | | | | | | | | RedirectingFS" This reverts the original commit and the follow up: Revert "[VirtualFileSystem] Support virtual working directory in the RedirectingFS" Revert "[test] Update YAML mapping in VirtualFileSystemTest" llvm-svn: 374935
* [test] Update YAML mapping in VirtualFileSystemTestJonas Devlieghere2019-10-151-6/+6
| | | | | | | The 'bar' directory should be part of the root rather than the file itself. llvm-svn: 374930
* [VirtualFileSystem] Support virtual working directory in the RedirectingFSJonas Devlieghere2019-10-151-4/+171
| | | | | | | | | | | | | | | | | | Before this patch, changing the working directory of the RedirectingFS would just forward to its external file system. This prevented us from having a working directory that only existed in the VFS mapping. This patch adds support for a virtual working directory in the RedirectingFileSystem. It now keeps track of its own WD in addition to updating the WD of the external file system. This ensures that we can still fall through for relative paths. This change was originally motivated by the reproducer infrastructure in LLDB where we want to deal transparently with relative paths. Differential revision: https://reviews.llvm.org/D65677 llvm-svn: 374917
* [Alignment][NFC] Move and type functions from MathExtras to AlignmentGuillaume Chatelet2019-10-143-5/+43
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68942 llvm-svn: 374773
* [Alignment][NFC] Support compile time constantsGuillaume Chatelet2019-10-142-0/+41
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68936 llvm-svn: 374758
* Unify the two CRC implementationsHans Wennborg2019-10-091-4/+19
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [NFC] [FileCheck] Reapply fix init of objects in unit testsThomas Preud'homme2019-10-041-20/+16
| | | | | | | | | | | | | | | | | | Summary: Fix initialization style of objects allocated on the stack and member objects in unit test to use the "Type Var(init list)" and "Type Member{init list}" convention. The latter fixes the buildbot breakage. Reviewers: jhenderson, probinson, arichardson, grimar, jdenny Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68425 llvm-svn: 373755
* Revert "[NFC] [FileCheck] Fix init of stack objects in unit tests"Dmitri Gribenko2019-10-041-16/+20
| | | | | | | This reverts commit r373717. It broke the build: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/18721. llvm-svn: 373722
* [NFC] [FileCheck] Fix init of stack objects in unit testsThomas Preud'homme2019-10-041-20/+16
| | | | | | | | | | | | | | | | Summary: Fix initialization style of objects allocated on the stack in unit test to use the "Type Var(init list)" convention. Reviewers: jhenderson, probinson, arichardson, grimar, jdenny Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68425 llvm-svn: 373717
* Revert "[Alignment][NFC] Allow constexpr Align"Guillaume Chatelet2019-10-032-29/+0
| | | | | | This reverts commit b3af236fb5fc6e50fcc1b54d868f0bff557f3fb1. llvm-svn: 373619
* [Alignment][NFC] Allow constexpr AlignGuillaume Chatelet2019-10-032-0/+29
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68329 llvm-svn: 373580
* [FileCheck] Move private interface to its own headerThomas Preud'homme2019-10-011-0/+2
| | | | | | | | | | | | | | | | | | | Summary: Most of the class definition in llvm/include/llvm/Support/FileCheck.h are actually implementation details that should not be relied upon. This commit moves all of it in a new header file under llvm/lib/Support/FileCheck. It also takes advantage of the code movement to put the code into a new llvm::filecheck namespace. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D67649 llvm-svn: 373395
* [Alignment][NFC] Adding a max function.Guillaume Chatelet2019-09-301-0/+23
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68201 llvm-svn: 373196
* [Alignment] Add a None() member functionGuillaume Chatelet2019-09-181-1/+4
| | | | | | | | | | | | | | | | | | | Summary: This will allow writing `if(A != llvm::Align::None())` which is clearer than `if(A > llvm::Align(1))` This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67697 llvm-svn: 372207
* [Support] Add writeFileAtomically() to FileUtilitiesJan Korous2019-09-052-0/+53
| | | | | | Differential Revision: https://reviews.llvm.org/D66859 llvm-svn: 371103
* [FileCheck] Forbid using var defined on same lineThomas Preud'homme2019-09-021-41/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Commit r366897 introduced the possibility to set a variable from an expression, such as [[#VAR2:VAR1+3]]. While introducing this feature, it introduced extra logic to allow using such a variable on the same line later on. Unfortunately that extra logic is flawed as it relies on a mapping from variable to expression defining it when the mapping is from variable definition to expression. This flaw causes among other issues PR42896. This commit avoids the problem by forbidding all use of a variable defined on the same line, and removes the now useless logic. Redesign will be done in a later commit because it will require some amount of refactoring first for the solution to be clean. One example is the need for some sort of transaction mechanism to set a variable temporarily and from an expression and rollback if the CHECK pattern does not match so that diagnostics show the right variable values. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D66141 llvm-svn: 370663
* Add error handling to the DataExtractor classPavel Labath2019-08-271-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is motivated by D63591, where we realized that there isn't a really good way of telling whether a DataExtractor is reading actual data, or is it just returning default values because it reached the end of the buffer. This patch resolves that by providing a new "Cursor" class. A Cursor object encapsulates two things: - the current position/offset in the DataExtractor - an error object Storing the error object inside the Cursor enables one to use the same pattern as the std::{io}stream API, where one can blindly perform a sequence of reads and only check for errors once at the end of the operation. Similarly to the stream API, as soon as we encounter one error, all of the subsequent operations are skipped (return default values) too, even if the would suceed with clear error state. Unlike the std::stream API (but in line with other llvm APIs), we force the error state to be checked through usage of llvm::Error. Reviewers: probinson, dblaikie, JDevlieghere, aprantl, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63713 llvm-svn: 370042
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-222-16/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-201-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | This recommits r368977, which was reverted in r369027 due to test failures in lldb. The cause of this was different behavior of readNativeFileSlice on windows and unix. These have been addressed in r369269. The original commit message was: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 369370
* Filesystem/Windows: fix inconsistency in readNativeFileSlice APIPavel Labath2019-08-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The windows version implementation of readNativeFileSlice, was trying to match the POSIX behavior of not treating EOF as an error, but it was only handling the case of reading from a pipe. Attempting to read past the end of a regular file returns a slightly different error code, which needs to be handled too. This patch adds ERROR_HANDLE_EOF to the list of error codes to be treated as an end of file, and adds some unit tests for the API. This issue was found while attempting to land D66224, which caused a bunch of lldb tests to start failing on windows. Reviewers: rnk, aganea Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66344 llvm-svn: 369269
* Revert "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-151-51/+0
| | | | | | This reverts commit r368977 because it broke a couple of tests in lldb. llvm-svn: 369027
* [LLVM][Alignment] Fix MSVC potential division by 0 warning (PR42911)Simon Pilgrim2019-08-151-0/+10
| | | | | | | | Original Patch by @gchatelet (Guillaume Chatelet) Differential Revision: https://reviews.llvm.org/D65859 llvm-svn: 369016
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-156-29/+29
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* MemoryBuffer: Add a missing error-check to getOpenFileImplPavel Labath2019-08-151-0/+51
| | | | | | | | | | | | | | | | | | | Summary: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 368977
OpenPOWER on IntegriCloud