summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [Support] Add ExitOnError utility to support tools that use the exit-on-errorLang Hames2016-03-171-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | idiom. Most LLVM tool code exits immediately when an error is encountered and prints an error message to stderr. The ExitOnError class supports this by providing two call operators - one for Errors, and one for Expected<T>s. Calls to code that can return Errors (or Expected<T>s) can use these calls to bail out on error, and otherwise continue as if the operation had succeeded. E.g. Error foo(); Expected<int> bar(); int main(int argc, char *argv[]) { ExitOnError ExitOnErr; ExitOnErr.setBanner(std::string("Error in ") + argv[0] + ":"); // Exit if foo returns an error. No need to manually check error return. ExitOnErr(foo()); // Exit if bar returns an error, otherwise unwrap the contained int and // continue. int X = ExitOnErr(bar()); // ... return 0; } llvm-svn: 263749
* [Support] Make Error::isA<T>() works on success values.Lang Hames2016-03-171-0/+3
| | | | llvm-svn: 263745
* [Support] Update Error unit test to remove implementation specific behaviour.Lang Hames2016-03-161-2/+1
| | | | llvm-svn: 263610
* [Support] Add the 'Error' class for structured error handling.Lang Hames2016-03-162-0/+459
| | | | | | | | | | | | | | | | | This patch introduces the Error classs for lightweight, structured, recoverable error handling. It includes utilities for creating, manipulating and handling errors. The scheme is similar to exceptions, in that errors are described with user-defined types. Unlike exceptions however, errors are represented as ordinary return types in the API (similar to the way std::error_code is used). For usage notes see the LLVM programmer's manual, and the Error.h header. Usage examples can be found in unittests/Support/ErrorTest.cpp. Many thanks to David Blaikie, Mehdi Amini, Kevin Enderby and others on the llvm-dev and llvm-commits lists for lots of discussion and review. llvm-svn: 263609
* MathExtrasTest.cpp: Use EXPECT_DOUBLE_EQ here, instead of EXPECT_FLOAT_EQ.NAKAMURA Takumi2016-03-141-1/+1
| | | | llvm-svn: 263508
* More UTF string conversion wrappersMarianne Mailhot-Sarrasin2016-03-111-1/+36
| | | | | | | | | | | Added new string conversion wrappers that convert between `std::string` (of UTF-8 bytes) and `std::wstring`, which is particularly useful for Win32 interop. Also fixed a missing string conversion for `getenv` on Win32, using these new wrappers. The motivation behind this is to provide the support functions required for LLDB to work properly on Windows with non-ASCII data; however, the functions are not LLDB specific. Patch by cameron314 Differential Revision: http://reviews.llvm.org/D17549 llvm-svn: 263247
* unitests: add some ARM TargetParser testsSaleem Abdulrasool2016-03-062-0/+52
| | | | | | | | | The ARM TargetParser would construct invalid StringRefs. This would cause asserts to trigger. Add some tests in LLVM to ensure that we dont regress on this in the future. Although there is a test for this in clang, this ensures that the changes would get caught in the same repository. llvm-svn: 262790
* Refactor duplicated code for linking with pthread.Rafael Espindola2016-03-011-3/+1
| | | | llvm-svn: 262344
* [Support] Add a fancy helper function to get a static name for a type.Chandler Carruth2016-02-252-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | This extracts the type name from __PRETTY_FUNCTION__ for compilers that support it (I've opted Clang, GCC, and ICC into this as I've tested that they work) and from __FUNCSIG__ which is very similar on MSVC. The routine falls back gracefully on a stub "UNKNOWN_TYPE" string with compilers or formats it doesn't understand. This should be enough for a lot of common cases in LLVM where the real goal is just to log or print a type name as a debugging aid, and save a ton of boilerplate in the process. Notably, I'm planning to use this to remove all the getName() boiler plate from the new pass manager. The design and implementation is based on a bunch of advice and discussion with Richard Smith and experimenting with most versions of Clang and GCC. David Majnemer also provided excellent advice on how best to do this with MSVC. Richard also checked that ICC does something reasonable and I'll watch the build bots for other compilers. It'd be great if someone could contribute logic for xlC and/or other toolchains. Differential Revision: http://reviews.llvm.org/D17565 llvm-svn: 261819
* Fix a -Wsign-compare in Support Path unittestsReid Kleckner2016-02-101-1/+1
| | | | llvm-svn: 260418
* Silence some MSVC warnings about zero extending unsigned to void*Reid Kleckner2016-02-101-4/+4
| | | | llvm-svn: 260413
* Use std::forward to make ErrorOr<T> constructible from a value that has a ↵Nick Lewycky2016-02-091-1/+41
| | | | | | user-defined conversion to T. No functionality change intended. llvm-svn: 260196
* Remove TrailingObjects::operator delete. It's still suffering fromRichard Smith2016-02-091-2/+2
| | | | | | | | | compiler-specific issues. Instead, repeat an 'operator delete' definition in each derived class that is actually deleted, and give up on the static type safety of an error when sized delete is accidentally used on a type derived from TrailingObjects. llvm-svn: 260190
* Re-commit r259942 (reverted in r260053) with a different workaround for the ↵Richard Smith2016-02-091-0/+2
| | | | | | | | | | | | | | | MSVC bug. This fixes undefined behavior in C++14 due to the size of the object being deleted being different from sizeof(dynamic type) when it is allocated with trailing objects. MSVC seems to have several bugs around using-declarations changing the access of a member inherited from a base class, so use forwarding functions instead of using-declarations to make TrailingObjects::operator delete accessible where desired. llvm-svn: 260180
* Revert 259942, r259943, r259948.Nico Weber2016-02-071-2/+0
| | | | | | | | | | | | | | | | The Windows bots have been failing for the last two days, with: FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe -c LLVMContextImpl.cpp D:\buildslave\clang-x64-ninja-win7\llvm\lib\IR\LLVMContextImpl.cpp(137) : error C2248: 'llvm::TrailingObjects<llvm::AttributeSetImpl, llvm::IndexAttrPair>::operator delete' : cannot access private member declared in class 'llvm::AttributeSetImpl' TrailingObjects.h(298) : see declaration of 'llvm::TrailingObjects<llvm::AttributeSetImpl, llvm::IndexAttrPair>::operator delete' AttributeImpl.h(213) : see declaration of 'llvm::AttributeSetImpl' llvm-svn: 260053
* More workarounds for undefined behavior exposed when compiling in C++14 withRichard Smith2016-02-051-0/+2
| | | | | | | | -fsized-deallocation. Disable sized deallocation for all objects derived from TrailingObjects, as we expect the storage allocated for these objects to be larger than the size of their dynamic type. llvm-svn: 259942
* [unittests] Move TargetRegistry test from Support to MCReid Kleckner2016-02-032-44/+0
| | | | | | | This removes the dependency from SupportTests to all of the LLVM backends, and makes it link faster. llvm-svn: 259705
* Silence -Wsign-conversion issue in ProgramTest.cppReid Kleckner2016-02-031-3/+3
| | | | | | | | Unfortunately, ProgramInfo::ProcessId is signed on Unix and unsigned on Windows, breaking the standard fix of using '0U' in the gtest expectation. llvm-svn: 259704
* Fixed compilation issue.Elena Demikhovsky2016-01-281-1/+1
| | | | llvm-svn: 259087
* Fix identify_magic() to check that a file that starts with MH_MAGIC isKevin Enderby2016-01-261-11/+19
| | | | | | | | | | | | at least as big as the mach header to be identified as a Mach-O file and make sure smaller files are not identified as a Mach-O files but as unknown files. Also fix identify_magic() so it looks at all 4 bytes of the filetype field when determining the type of the Mach-O file. Then fix the macho-invalid-header test case to check that it is an unknown file and make sure it does not get the error for object_error::parse_failed. And also update the unit tests. llvm-svn: 258883
* Remove autoconf supportChris Bieneman2016-01-261-15/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; ↵Eugene Zelenko2016-01-261-4/+4
| | | | | | | | other minor fixes. Differential revision: reviews.llvm.org/D16568 llvm-svn: 258831
* Add a test showing we can write a vector of floats.Rafael Espindola2016-01-251-0/+21
| | | | llvm-svn: 258701
* Add ArrayRef support to EndianStream.Rafael Espindola2016-01-221-0/+30
| | | | | | | | | | Using an array instead of ArrayRef would allow type inference, but (short of using C99) one would still need to write typedef uint16_t VT[]; LE.write(VT{0x1234, 0x5678}); llvm-svn: 258535
* Update to use new name alignTo().Rui Ueyama2016-01-142-15/+14
| | | | llvm-svn: 257804
* [Support] Add saturating multiply-add support functionNathan Slingerland2016-01-121-0/+54
| | | | | | | | | | | | Summary: Add SaturatingMultiplyAdd convenience function template since A + (X * Y) comes up frequently when doing weighted arithmetic. Reviewers: davidxl, silvas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15385 llvm-svn: 257532
* Add != to YAMLParser's basic_collection_iterator.Jordan Rose2016-01-061-0/+72
| | | | | | | | | ...and mark it as merely an input_iterator rather than a forward_iterator, since it is destructive. And then rewrite == to take advantage of that. Patch by Alex Denisov! llvm-svn: 256913
* [ADT] Teach alignment helpers to work correctly for abstract classes.Chandler Carruth2015-12-291-0/+20
| | | | | | | | | | | | This is necessary to use them as part of pointer traits and is generally useful. I've added unit test coverage to isolate and ensure this works correctly. I'll watch the build bots to try to see if any compilers can't tolerate this bit of magic (and much credit goes to Richard Smith for coming up with this magical production!) but give a shout if you see issues. llvm-svn: 256553
* [TrailingObjects] Dynamically realign under-aligned trailing objects.James Y Knight2015-12-291-0/+17
| | | | | | | | | | | | | | Previously, the code enforced non-decreasing alignment of each trailing type. However, it's easy enough to allow for realignment as needed, and thus avoid the developer having to think about the possiblilities for alignment requirements on all architectures. (E.g. on Linux/x86, a struct with an int64 member is 4-byte aligned, while on other 32-bit archs -- and even with other OSes on x86 -- it has 8-byte alignment. This sort of thing is irritating to have to manually deal with.) llvm-svn: 256533
* Unbreak LLVM_ENABLE_THREADS=OFF builds.Nico Weber2015-12-231-3/+19
| | | | llvm-svn: 256308
* [unittest] Use Support/thread.h instead of <thread> (second try)Vedant Kumar2015-12-221-1/+1
| | | | llvm-svn: 256292
* [unittest] Use Support/Thread.h instead of <thread> to fix the Windows buildVedant Kumar2015-12-221-1/+1
| | | | llvm-svn: 256290
* [Support] Allow multiple paired calls to {start,stop}Timer()Vedant Kumar2015-12-222-0/+50
| | | | | | | Differential Revision: http://reviews.llvm.org/D15619 Reviewed-by: rafael llvm-svn: 256258
* fix leak in a test, make the sanitizer bot greenKostya Serebryany2015-12-211-1/+2
| | | | llvm-svn: 256179
* ThreadPool unittests: do not hold mutex when calling condition_variable:notify()Mehdi Amini2015-12-191-11/+11
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256111
* [unittests] ThreadPool: Remove redundant loop, NFCVedant Kumar2015-12-191-4/+2
| | | | llvm-svn: 256097
* [unittests] ThreadPool: Guard updates to MainThreadReadyVedant Kumar2015-12-191-12/+16
| | | | llvm-svn: 256096
* ThreadPool unittest: reimplement concurrency test, deterministically this time.Mehdi Amini2015-12-191-5/+36
| | | | | | | Follow-up to r256056. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256087
* Remove possibility of failures to due race in ThreadPool unittestTeresa Johnson2015-12-181-22/+0
| | | | | | | | Remove all checks that required main thread to run faster than tasks in ThreadPool, and yields which are now unnecessary. This should fix some bot failures. llvm-svn: 256056
* Rewrite the TrailingObjects template to provide two new features:James Y Knight2015-12-181-4/+34
| | | | | | | | | | | | | | - Automatic alignment of the base type for the alignment requirements of the trailing types. - Support for an arbitrary numbers of trailing types, instead of only 1 or 2, by using a variadic template implementation. Upcoming commits to clang will take advantage of both of these features. Differential Revision: http://reviews.llvm.org/D12439 llvm-svn: 256054
* BranchProbabilityTest.cpp: Suppress warnings. [-Wsign-compare]NAKAMURA Takumi2015-12-181-3/+3
| | | | llvm-svn: 255940
* [BranchProbability] Remove the restriction that known and unknown ↵Cong Hou2015-12-171-0/+31
| | | | | | | | | | | | | | | | | | | probabilities cannot coexist when being normalized. The current BranchProbability::normalizeProbabilities() forbids known and unknown probabilities to coexist in the list. This was once used to help capture probability exceptions but has caused some reported build failures (https://llvm.org/bugs/show_bug.cgi?id=25838). This patch removes this restriction by evenly distributing the complement of the sum of all known probabilities to unknown ones. We could still treat this as an abnormal behavior, but it is better to emit warnings in our future profile validator. Differential revision: http://reviews.llvm.org/D15548 llvm-svn: 255934
* Mark ThreadPool unittests as unsupported on PowerPC64Mehdi Amini2015-12-151-0/+4
| | | | | | | Bots are crashing unexpectingly, see: https://llvm.org/bugs/show_bug.cgi?id=25829 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255633
* ThreadPool unittest: add a rough mechanism to mark UNSUPPORTED on a given ↵Mehdi Amini2015-12-151-5/+53
| | | | | | | platform From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255632
* Replace the unit test of BranchProbability::normalizeEdgeWeights() with ↵Cong Hou2015-12-151-29/+25
| | | | | | | | BranchProbability::normalizeProbabilities(). BranchProbability::normalizeEdgeWeights() is going to be retired soon. llvm-svn: 255618
* Fix template parameter pack handling in ThreadPoolTeresa Johnson2015-12-151-0/+14
| | | | | | | Fixes passing of template parameter pack via std::forward and add unittest. llvm-svn: 255617
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-152-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Recommit of r255589, trying to please g++ as well. Differential Revision: http://reviews.llvm.org/D15464 From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 255593
* Revert "Add a C++11 ThreadPool implementation in LLVM"Mehdi Amini2015-12-152-92/+0
| | | | | | | This reverts commit r255589. Breaks g++ From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255591
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-152-0/+92
| | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Differential Revision: http://reviews.llvm.org/D15464 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255589
* Revert r255444.Nico Weber2015-12-132-92/+0
| | | | | | | | It doesn't build on Windows and broke the Windows LLD and LLDB bots: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/27693/steps/build_Lld/logs/stdio http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/13468/steps/build/logs/stdio llvm-svn: 255446
OpenPOWER on IntegriCloud