summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
* [Support] Introduce createStringError helper functionVictor Leschuk2018-07-261-0/+23
| | | | | | | | | | | The function in question is copy-pasted lots of times in DWARF-related classes. Thus it will make sense to place its implementation into the Support library. Reviewed by: lhames Differential Revision: https://reviews.llvm.org/D49824 llvm-svn: 337995
* [DebugCounters] Keep track of total countsGeorge Burgess IV2018-07-232-0/+43
| | | | | | | | | | | | | | This patch makes debug counters keep track of the total number of times we've called `shouldExecute` for each counter, so it's easier to build automated tooling on top of these. A patch to print these counts is coming soon. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D49560 llvm-svn: 337748
* [Support] Require llvm::Error passed to formatv() to be wrapped in fmt_consume()Sam McCall2018-07-121-0/+9
| | | | | | | | | | | | | | | | | | Summary: Someone must be responsible for handling an Error. When formatv takes ownership of an Error, the formatv_object destructor must take care of this. Passing an error by value to formatv() is not considered explicit enough to mark the error as handled (see D49013), so we require callers to use a format adapter to confirm this intent. Reviewers: zturner Subscribers: llvm-commits, lhames Differential Revision: https://reviews.llvm.org/D49170 llvm-svn: 336888
* [Support] Harded JSON against invalid UTF-8.Sam McCall2018-07-101-0/+33
| | | | | | | | | Parsing invalid UTF-8 input is now a parse error. Creating JSON values from invalid UTF-8 now triggers an assertion, and (in no-assert builds) substitutes the unicode replacement character. Strings retrieved from json::Value are always valid UTF-8. llvm-svn: 336657
* [Support] Allow JSON serialization of Optional<T> for supported T.Sam McCall2018-07-091-0/+2
| | | | | | This is ported from r333881 to JSON's new home. llvm-svn: 336542
* [Support] Make JSON handle doubles and int64s losslesslySam McCall2018-07-091-0/+60
| | | | | | | | | | | | | | | | | | | Summary: This patch adds a new "integer" ValueType, and renames Number -> Double. This allows us to preserve the full precision of int64_t when parsing integers from the wire, or constructing from an integer. The API is unchanged, other than giving asInteger() a clearer contract. In addition, always output doubles with enough precision that parsing will reconstruct the same double. Reviewers: simon_tatham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46209 llvm-svn: 336541
* Lift JSON library from clang-tools-extra/clangd to llvm/Support.Sam McCall2018-07-092-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This consists of four main parts: - an type json::Expr representing JSON values of dynamic kind, which can be composed, inspected, and modified - a JSON parser from string -> json::Expr - a JSON printer from json::Expr -> string, with optional pretty-printing - a convention for mapping json::Expr <=> native types (fromJSON/toJSON) Mapping functions are provided for primitives (e.g. int, vector) and the ObjectMapper helper helps implement fromJSON for struct/object types. Based on clangd's usage, a couple of places I'd appreciate review attention: - fromJSON returns only bool. A richer error-signaling mechanism may be useful to provide useful messages, or let recursive fromJSONs (containers/structs) do careful error recovery. - should json::obj be always explicitly written (like json::ary) - there's no streaming parse API. I suspect there are some simple wins like a callback API where the document is a long array, and each element is small. But this can probably be bolted on easily when we see the need. Reviewers: bkramer, labath Subscribers: mgorny, ilya-biryukov, ioeric, MaskRay, llvm-commits Differential Revision: https://reviews.llvm.org/D45753 llvm-svn: 336534
* [Support] Clear errno before calling the function in RetryAfterSignal.Chandler Carruth2018-07-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | For certain APIs, the return value of the function does not distinguish between failure (which populates errno) and other non-error conditions (which do not set errno). For example, `fgets` returns `NULL` both when an error has occurred, or upon EOF. If `errno` is already `EINTR` for whatever reason, then ``` RetryAfterSignal(nullptr, fgets, ...); ``` on a stream that has reached EOF would infinite loop. Fix this by setting `errno` to `0` before each attempt in `RetryAfterSignal`. Patch by Ricky Zhou! Differential Revision: https://reviews.llvm.org/D48755 llvm-svn: 336479
* [Support] Make support types more easily printable.Sam McCall2018-07-062-10/+38
| | | | | | | | | | | | | | | Summary: Error's new operator<< is the first way to print an error without consuming it. formatv() can now print objects with an operator<< that works with raw_ostream. Reviewers: bkramer Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D48966 llvm-svn: 336412
* Silence an MSVC C4189 warning about a local variable being initialized but ↵Aaron Ballman2018-07-041-1/+0
| | | | | | not used; NFC. llvm-svn: 336298
* [ThinLTO] Update ThinLTO cache file atimes when on WindowsAndrew Ng2018-07-041-0/+32
| | | | | | | | | | | | | | | | | | ThinLTO cache file access times are used for expiration based pruning and since Vista, file access times are not updated by Windows by default: https://blogs.technet.microsoft.com/filecab/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance This means on Windows, cache files are currently being pruned from creation time. This change manually updates cache files that are accessed by ThinLTO, when on Windows. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D47266 llvm-svn: 336276
* [Support] This sanity check in the test only works with certain versionsChandler Carruth2018-07-031-1/+1
| | | | | | | | | | | of libstdc++, not just certain versions of GCC. The original macros broke when using Clang + libstdc++4.9 sadly. Sadly, testing for versions of libstdc++ has been extremely problematic in the past, so I'm just narrowing this down to Windows and when using libc++ as that seems at least very unlikely to keep build bots broken. llvm-svn: 336174
* [Support] Fix llvm::unique_function when building with GCC 4.9 byChandler Carruth2018-07-032-0/+78
| | | | | | | | | | | | | | | | | | | introducing llvm::trivially_{copy,move}_constructible type traits. This uses a completely portable implementation of these traits provided by Richard Smith. You can see it on compiler explorer in all its glory: https://godbolt.org/g/QEDZjW I have transcribed it, clang-formatted it, added some comments, and made the tests fit into a unittest file. I have also switched llvm::unique_function over to use these new, much more portable traits. =D Hopefully this will fix the build bot breakage from my prior commit. llvm-svn: 336161
* [SupportTests] Silence -Wsign-compare warningsBenjamin Kramer2018-06-281-2/+2
| | | | llvm-svn: 335921
* Fix padding with custom character in formatv.Zachary Turner2018-06-281-0/+62
| | | | | | | | | | | The format string for formatv allows to specify a custom padding character instead of the default space. This custom character was parsed correctly, but not passed on to the formatter. Patch by Marcel Köppe Differential Revision: https://reviews.llvm.org/D48140 llvm-svn: 335915
* Add a flag to FileOutputBuffer that allows modification.Zachary Turner2018-06-281-0/+50
| | | | | | | | | | | | | FileOutputBuffer creates a temp file and on commit atomically renames the temp file to the destination file. Sometimes we want to modify an existing file in place, but still have the atomicity guarantee. To do this we can initialize the contents of the temp file from the destination file (if it exists), that way the resulting FileOutputBuffer can have only selective bytes modified. Committing will then atomically replace the destination file as desired. llvm-svn: 335902
* Build TaskQueueTest in threads=on builds, fixes regression from r335608.Nico Weber2018-06-271-0/+2
| | | | llvm-svn: 335724
* Fix LLVM_ENABLE_THREADS=0 builds after r335440.Nico Weber2018-06-261-1/+2
| | | | llvm-svn: 335608
* One more build fix for non MSVC compilers.Zachary Turner2018-06-251-6/+6
| | | | llvm-svn: 335443
* Add a TaskQueue that can serialize work on a ThreadPool.Zachary Turner2018-06-252-0/+106
| | | | | | | | | | | | We have ThreadPool, which can execute work asynchronously on N background threads, but sometimes you need to make sure the work is executed asynchronously but also serially. That is, if task B is enqueued after task A, then task B should not begin until task A has completed. This patch adds such a class. Differential Revision: https://reviews.llvm.org/D48240 llvm-svn: 335440
* Revert "Enable ThreadPool to queue tasks that return values."Zachary Turner2018-06-131-19/+0
| | | | | | | | This is failing to compile when LLVM_ENABLE_THREADS is false, and the fix is not immediately obvious, so reverting while I look into it. llvm-svn: 334658
* Enable ThreadPool to support tasks that return values.Zachary Turner2018-06-131-0/+19
| | | | | | | | | | | | | | | | | | | | | Previously ThreadPool could only queue async "jobs", i.e. work that was done for its side effects and not for its result. It's useful occasionally to queue async work that returns a value. From an API perspective, this is very intuitive. The previous API just returned a shared_future<void>, so all we need to do is make it return a shared_future<T>, where T is the type of value that the operation returns. Making this work required a little magic, but ultimately it's not too bad. Instead of keeping a shared queue<packaged_task<void()>> we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase is a class with a pure virtual execute() method, then have a templated derived class that stores a packaged_task<T()>. Everything else works out pretty cleanly. Differential Revision: https://reviews.llvm.org/D48115 llvm-svn: 334643
* Add checkMulAdd helper function to CheckedArithmeticGeorge Karpenkov2018-06-131-0/+25
| | | | | | | | | | Multiplication followed by addition (https://en.wikipedia.org/wiki/Multiply–accumulate_operation) is a sufficiently common use-case to warrant a separate helper. Differential Revision: https://reviews.llvm.org/D48138 llvm-svn: 334635
* Change checked arithmetic functions API to return OptionalGeorge Karpenkov2018-06-131-34/+22
| | | | | | | | | | Returning optional is much safer. The previous API had potential to cause use of undefined variables, if the value passed by pointer was accidentally read afterwards. Differential Revision: https://reviews.llvm.org/D48137 llvm-svn: 334634
* Do not enforce absolute path argv0 in windowsHans Wennborg2018-06-131-0/+19
| | | | | | | | | | | | | | | | Even if we support no-canonical-prefix on clang-cl(https://reviews.llvm.org/D47480), argv0 becomes absolute path in clang-cl and that embeds absolute path in /showIncludes. This patch removes such full path normalization from InitLLVM on windows, and that removes absolute path from clang-cl output (obj/stdout/stderr) when debug flag is disabled. Patch by Takuto Ikuta! Differential Revision https://reviews.llvm.org/D47578 llvm-svn: 334602
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-122-40/+24
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-112-0/+51
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [Unittests] Change linker flags of dynamic library testsMikhail Maltsev2018-06-111-1/+8
| | | | | | | | | | | | | | | | | | | A recent change https://reviews.llvm.org/D46898 which had no intended behavior change, actually modified the linker flags used when linking the dynamic libraries used by the DynamicLibraryTests unit test. This made the test fail in our testing environment which runs the tests from an NFS share. Prior to D46898 the two libraries used by the test were different (because the library name used to be embedded into the binary), and after the change they became bit-to-bit identical. This causes dlopen to return the same handle when these two libraries are loaded from an NFS share, and the test expects two different handles. This patch reverts the part of D46898 that is responsible for changing the linker flags. Differential Revision: https://reviews.llvm.org/D47469 llvm-svn: 334394
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-074-5/+228
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [AArch64, ARM] Add support for Samsung Exynos M4Evandro Menezes2018-06-061-8/+19
| | | | | | Create a separate feature set for Exynos M4 and add test cases. llvm-svn: 334115
* [YAML] Quote multiline string scalarsIlya Biryukov2018-05-301-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Otherwise, the YAML parser breaks when trying to read them back in 'key: multiline_string_value' cases. This patch fixes a problem when serializing structs which contain multi-line strings. E.g., if we try to serialize the following struct ``` { "key1": "first line\nsecond line", "key2": "another string" }` ``` Before this patch, we got the YAML output that failed to parse: ``` key1: first line second line key2: another string ``` After the patch, we get: ``` key1: 'first line second line' key2: another string ``` Reviewers: sammccall Reviewed By: sammccall Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47468 llvm-svn: 333527
* Support: Simplify endian stream interface. NFCI.Peter Collingbourne2018-05-181-11/+11
| | | | | | | | | | | | Provide some free functions to reduce verbosity of endian-writing a single value, and replace the endianness template parameter with a field. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47032 llvm-svn: 332757
* use standard llvm cmake formatting for targets defined in plugin testsNico Weber2018-05-181-3/+9
| | | | llvm-svn: 332709
* Revert 332508 as it caused problems in the clang test suite.Greg Clayton2018-05-161-3/+2
| | | | llvm-svn: 332555
* Fix llvm::sys::path::remove_dots() to return "." instead of an empty path.Greg Clayton2018-05-161-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D46887 llvm-svn: 332508
* Give shared modules in unittests the platform-native extension, make ↵Nico Weber2018-05-162-12/+7
| | | | | | | | | | | | | | | | | PipSqueak a MODULE As far as I can tell from revision history, there's no good reason to call these files .so instead of .dll in Windows, so use the normal extension. Also change PipSquak from SHARED to MODULE -- it's never passed to target_link_libraries() and only loaded via dlopen(), so MODULE is more appropriate. This makes it possible to delete a workaround for SHARED ldflags being not quite right as well. No intended behavior change. https://reviews.llvm.org/D46898 llvm-svn: 332487
* Use perfect forwarding to deduplicate code in unit test. NFC.Benjamin Kramer2018-05-151-22/+2
| | | | llvm-svn: 332388
* Rename three cxx files in unittests to cpp.Nico Weber2018-05-153-5/+8
| | | | | | | | | | | | LLVM uses cpp as its C++ file extension, these are the only three cxx file in the monorepo. These files apparently were called to escape a CMake check -- use the LLVM_OPTIONAL_SOURCES mechanism that's meant as an escape for this case instead. No intended behavior change. https://reviews.llvm.org/D46843 llvm-svn: 332368
* Fix broken asan Support testsEric Liu2018-05-151-8/+14
| | | | | | | | The asan failures were caught in google internal asan tests after r332311 o Make StackOption support cl::list o Rememeber to removeArguments for cl::alias in tests. llvm-svn: 332354
* [CommandLine] Error message for incorrect PositionalEatArgs usageKeno Fischer2018-05-141-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: bugpoint has several options specified as `PositionalEatArgs` to pass options through to the underlying tool, e.g. `-tool-args`. The `-help` message suggests the usage is: `-tool-args=<string>`. However, this is misleading, because that's not how these arguments work. Rather than taking a value, the option consumes all positional arguments until the next recognized option (or all arguments if `--` is specified at some point). To make this slightly clearer, instead print the help as: ``` -tool-args <string>... - <tool arguments>... ``` Additionally, add an error if the user attempts to use a `PositionalEatArgs` argument with a value, instead of silently ignoring it. Example: ``` ./bin/bugpoint -tool-args=-mpcu=skylake-avx512 bugpoint: for the -tool-args option: This argument does not take a value. Instead, it consumes any positional arguments until the next recognized option. ``` Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D46787 llvm-svn: 332311
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Various path functions were not treating paths consisting of slashes alone consistently. For example, the iterator-based accessors decomposed the path "///" into two elements: "/" and ".". This is not too bad, but it is different from the behavior specified by posix: ``` A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. ``` More importantly, this was different from how we treated the same path in the filename+parent_path functions, which decomposed this path into "." and "". This was completely wrong as it lost the information that this was an absolute path which referred to the root directory. This patch fixes this behavior by making sure all functions treat paths consisting of (back)slashes alone the same way as "/". I.e., the iterator-based functions will just report one component ("/"), and the filename+parent_path will decompose them into "/" and "". A slightly controversial topic here may be the treatment of "//". Posix says that paths beginning with "//" may have special meaning and indeed we have code which parses paths like "//net/foo/bar" specially. However, as we were already not being consistent in parsing the "//" string alone, and any special parsing for it would complicate the code further, I chose to treat it the same way as longer sequences of slashes (which are guaranteed to be the same as "/"). Another slight change of behavior is in the parsing of paths like "//net//". Previously the last component of this path was ".". However, as in our parsing the "//net" part in this path was the same as the "drive" part in "c:\" and the next slash was the "root directory", it made sense to treat "//net//" the same way as "//net/" (i.e., not to add the extra "." component at the end). Reviewers: zturner, rnk, dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45942 llvm-svn: 331876
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-012-2/+2
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-303-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-295-22/+22
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* [Support/Path] Add more tests and improve failure messages of existing onesPavel Labath2018-04-241-102/+52
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I am preparing a patch to the path function. While working on it, I noticed that some of the areas are lacking test coverage (e.g. filename and parent_path functions), so I add more tests to guard against regressions there. I have also found the failure messages hard to understand, so I rewrote some existing test to give more actionable messages when they fail: - for tests which run over multiple inputs, I use SCOPED_TRACE, to show which of the inputs caused the actual failure. - for comparisons of vectors, I use gmock's container matchers, which will print out the full container contents (and the elements that differ) when they fail to match. Reviewers: zturner, espindola Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45941 llvm-svn: 330691
* [Testing/Support] Make Failed() matcher work with abstract error typesPavel Labath2018-04-101-0/+1
| | | | | | | | | | | | Failed<ErrorInfoBase>() did not compile, because it was attempting to create a copy of the Error object when passing it to the nested matcher, which was not possible because ErrorInfoBase is abstract. This commit fixes the problem by making sure we pass the ErrorInfo object by reference, which also improves the handling of non-abstract objects, as we avoid potentially slicing an object during the copy. llvm-svn: 329703
* Fix stack-use-after-scope in test previously hidden by -fmerge-all-constantsVitaly Buka2018-04-071-3/+3
| | | | llvm-svn: 329489
* [unittests] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-071-6/+6
| | | | | | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. llvm-svn: 329475
* [Support] Make line-number cache robust against access patterns.Graydon Hoare2018-04-071-0/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang) has a routine for looking up line numbers of SMLocs. This routine uses a shared, special-purpose cache that handles exactly one access pattern efficiently: looking up the line number of an SMLoc that points into the same buffer as the last query made to the SourceMgr, at a location in the buffer at or ahead of the last query. When this works it's fine, but when it fails it's catastrophic for performancer: one recent out-of-order access from a Swift utility routine ran for tens of seconds, spending 99% of its time repeatedly scanning buffers for '\n'. This change removes the shared cache from the SourceMgr and installs a new cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense that rather than caching a single last-query pointer, they cache _all_ the line-ending offsets, in a binary-searchable array, such that once it's populated (on first access), all subsequent access patterns run at the same speed. Performance measurements I've done show this is actually a little bit faster on real codebases (though only a couple fractions of a percent). Memory usage is up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done on it; I've attempted to minimize this by using dynamic selection of integer sized when storing offset arrays. But the main motive here is to make-impossible the cases we don't always see, that show up by surprise when there is an out-of-order access pattern. Reviewers: jordan_rose Reviewed By: jordan_rose Subscribers: probinson, llvm-commits Differential Revision: https://reviews.llvm.org/D45003 llvm-svn: 329470
* [llvm-cov] Prevent llvm-cov from hanging when a symblink doesn't exist.Max Moroz2018-04-051-40/+73
| | | | | | | | | | | | | | | | | | | | Summary: Previous code hangs indefinitely when trying to iterate through a symbol link file that points to an non-exist directory. This change fixes the bug to make the addCollectedPath function exit ealier and print out correct warning messages. Patch by Yuke Liao (@liaoyuke). Reviewers: Dor1s, vsk Reviewed By: vsk Subscribers: bruno, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D44960 llvm-svn: 329338
OpenPOWER on IntegriCloud