summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* [Testing/Support]: Better matching of Error failure statesPavel Labath2018-04-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The existing Failed() matcher only allowed asserting that the operation failed, but it was not possible to verify any details of the returned error. This patch adds two new matchers, which make this possible: - Failed<InfoT>() verifies that the operation failed with a single error of a given type. - Failed<InfoT>(M) additionally check that the contained error info object is matched by the nested matcher M. To make these work, I've changed the implementation of the ErrorHolder class. Now, instead of just storing the string representation of the Error, it fetches the ErrorInfo objects and stores then as a list of shared pointers. This way, ErrorHolder remains copyable, while still retaining the full information contained in the Error object. In case the Error object contains two or more errors, the new matchers will fail to match, instead of trying to match all (or any) of the individual ErrorInfo objects. This seemed to be the most sensible behavior for when one wants to match exact error details, but I could be convinced otherwise... Reviewers: zturner, lhames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44925 llvm-svn: 329288
* [YAML] Remove unit test of multibyte non-printable escaping that uses C++11 ↵Graydon Hoare2018-03-271-1/+0
| | | | | | escapes llvm-svn: 328665
* [YAML] Escape non-printable multibyte UTF8 in Output::scalarString.Graydon Hoare2018-03-271-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing YAML Output::scalarString code path includes a partial and incorrect implementation of YAML escaping logic. In particular, the logic put in place in rL321283 escapes non-printable bytes only if they are not part of a multibyte UTF8 sequence; implicitly this means that all multibyte UTF8 sequences -- printable and non -- are passed through verbatim. The simplest solution to this is to direct the Output::scalarString method to use the standalone yaml::escape function, and this _almost_ works, except that the existing code in that function _over_ escapes: any multibyte UTF8 sequence is escaped, even printable ones. While this is permitted for YAML, it is also more aggressive (and hard to read for non-English locales) than necessary, and the entire point of rL321283 was to back off such aggressive over-escaping. So in this change, I have both redirected Output::scalarString to use yaml::escape _and_ modified yaml::escape to optionally restrict its escaping to non-printables. This preserves behaviour of any existing clients while giving them a path to more moderate escaping should they desire. Reviewers: JDevlieghere, thegameg, MatzeB, vladimir.plyashkun Reviewed By: thegameg Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44863 llvm-svn: 328661
* [Support] Pacify -Wsign-compare in unit test.Benjamin Kramer2018-03-081-2/+2
| | | | llvm-svn: 327070
* [Support] Add WriteThroughMemoryBuffer.Zachary Turner2018-03-081-0/+29
| | | | | | | | | | | This is like MemoryBuffer (read-only) and WritableMemoryBuffer (writable private), but where the underlying file can be modified after writing. This is useful when you want to open a file, make some targeted edits, and then write it back out. Differential Revision: https://reviews.llvm.org/D44230 llvm-svn: 327057
* On Windows we need to be able to process response files with Windows-styleDmitry Mikulin2018-03-051-0/+35
| | | | | | | | path names. Differential Revision: https://reviews.llvm.org/D43988 llvm-svn: 326737
* Utility functions for checked arithmeticGeorge Karpenkov2018-03-022-0/+72
| | | | | | | | | Provide checkedAdd and checkedMul functions, providing checked arithmetic on signed integers. Differential Revision: https://reviews.llvm.org/D43704 llvm-svn: 326516
* Resubmit r325107 (case folding DJB hash)Pavel Labath2018-02-212-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue was that the has function was generating different results depending on the signedness of char on the host platform. This commit fixes the issue by explicitly using an unsigned char type to prevent sign extension and adds some extra tests. The original commit message was: This patch implements a variant of the DJB hash function which folds the input according to the algorithm in the Dwarf 5 specification (Section 6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18, "Case Mappings"). To achieve this, I have added a llvm::sys::unicode::foldCharSimple function, which performs this mapping. The implementation of this function was generated from the CaseMatching.txt file from the Unicode spec using a python script (which is also included in this patch). The script tries to optimize the function by coalescing adjecant mappings with the same shift and stride (terms I made up). Theoretically, it could be made a bit smarter and merge adjecant blocks that were interrupted by only one or two characters with exceptional mapping, but this would save only a couple of branches, while it would greatly complicate the implementation, so I deemed it was not worth it. Since we assume that the vast majority of the input characters will be US-ASCII, the folding hash function has a fast-path for handling these, and only whips out the full decode+fold+encode logic if we encounter a character outside of this range. It might be possible to implement the folding directly on utf8 sequences, but this would also bring a lot of complexity for the few cases where we will actually need to process non-ascii characters. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D42740 llvm-svn: 325732
* Report fatal error in the case of out of memorySerge Pavlov2018-02-202-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
OpenPOWER on IntegriCloud