1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-02-01 05:01:59 +01:00
llvm-mirror/unittests/Support/CMakeLists.txt

122 lines
3.1 KiB
CMake
Raw Normal View History

set(LLVM_LINK_COMPONENTS
Support
)
add_llvm_unittest(SupportTests
AlignmentTest.cpp
AlignOfTest.cpp
AllocatorTest.cpp
AnnotationsTest.cpp
ARMAttributeParser.cpp
ArrayRecyclerTest.cpp
Base64Test.cpp
BinaryStreamTest.cpp
BlockFrequencyTest.cpp
BranchProbabilityTest.cpp
CachePruningTest.cpp
CrashRecoveryTest.cpp
Casting.cpp
CheckedArithmeticTest.cpp
Chrono.cpp
CommandLineTest.cpp
CompressionTest.cpp
ConvertUTFTest.cpp
CRCTest.cpp
DataExtractorTest.cpp
DebugTest.cpp
DebugCounterTest.cpp
Resubmit r325107 (case folding DJB hash) 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
2018-02-21 22:36:31 +00:00
DJBTest.cpp
EndianStreamTest.cpp
EndianTest.cpp
ELFAttributeParserTest.cpp
ErrnoTest.cpp
ErrorOrTest.cpp
ErrorTest.cpp
ExtensibleRTTITest.cpp
FileCollectorTest.cpp
FileOutputBufferTest.cpp
FileUtilitiesTest.cpp
FormatVariadicTest.cpp
GlobPatternTest.cpp
Host.cpp
IndexedAccessorTest.cpp
ItaniumManglingCanonicalizerTest.cpp
JSONTest.cpp
KnownBitsTest.cpp
LEB128Test.cpp
LineIteratorTest.cpp
LockFileManagerTest.cpp
MatchersTest.cpp
MD5Test.cpp
ManagedStatic.cpp
MathExtrasTest.cpp
MemoryBufferTest.cpp
MemoryTest.cpp
NativeFormatTests.cpp
OptimizedStructLayoutTest.cpp
ParallelTest.cpp
Path.cpp
ProcessTest.cpp
ProgramTest.cpp
RegexTest.cpp
ReverseIterationTest.cpp
ReplaceFileTest.cpp
RISCVAttributeParserTest.cpp
ScaledNumberTest.cpp
SourceMgrTest.cpp
SpecialCaseListTest.cpp
SuffixTreeTest.cpp
SwapByteOrderTest.cpp
SymbolRemappingReaderTest.cpp
TarWriterTest.cpp
TargetParserTest.cpp
TaskQueueTest.cpp
ThreadLocalTest.cpp
ThreadPool.cpp
Threading.cpp
TimerTest.cpp
[Support] Use outs() in ToolOutputFile Summary: If the output filename was specified as "-", the ToolOutputFile class would create a brand new raw_ostream object referring to the stdout. This patch changes it to reuse the llvm::outs() singleton. At the moment, this change should be "NFC", but it does enable other enhancements, like the automatic stdout/stderr synchronization as discussed on D80803. I've checked the history, and I did not find any indication that this class *has* to use a brand new stream object instead of outs() -- indeed, it is special-casing "-" in a number of places already, so this change fits the pattern pretty well. I suspect the main reason for the current state of affairs is that the class was originally introduced (r111595, in 2010) as a raw_fd_ostream subclass, which made any other solution impossible. Another potential benefit of this patch is that it makes it possible to move the raw_ostream class out of the business of special-casing "-" for stdout handling. That state of affairs does not seem appropriate because "-" is a valid filename (albeit hard to access with a lot of command line tools) on most systems. Handling "-" in ToolOutputFile seems more appropriate. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 12:08:45 +02:00
ToolOutputFileTest.cpp
TypeNameTest.cpp
TypeTraitsTest.cpp
TrailingObjectsTest.cpp
TrigramIndexTest.cpp
UnicodeTest.cpp
VersionTupleTest.cpp
VirtualFileSystemTest.cpp
WithColorTest.cpp
YAMLIOTest.cpp
YAMLParserTest.cpp
2012-09-14 23:36:56 +00:00
formatted_raw_ostream_test.cpp
raw_fd_stream_test.cpp
raw_ostream_test.cpp
raw_pwrite_stream_test.cpp
raw_sha1_ostream_test.cpp
xxhashTest.cpp
)
target_link_libraries(SupportTests PRIVATE LLVMTestingSupport)
# Disable all warning for AlignOfTest.cpp,
# as it does things intentionally, and there is no reliable way of
# disabling all warnings for all the compilers by using pragmas.
# Don't disable on MSVC, because all incriminated warnings are already disabled
# in source; and because we would otherwise see this warning:
# cl : Command line warning D9025: overriding '/W4' with '/w'
if(NOT MSVC)
set_source_files_properties(AlignOfTest.cpp PROPERTIES COMPILE_FLAGS -w)
endif()
if(MSVC)
if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 19.14 )
# Since VS2017 15.8, the following snippet: Failed<CustomSubError>()
# generates a warning:
# \svn\llvm\utils\unittest\googlemock\include\gmock\gmock-matchers.h(186):
# warning C5046: 'testing::MatcherInterface<T>::~MatcherInterface': Symbol involving type with internal linkage not defined
set_source_files_properties(ErrorTest.cpp PROPERTIES COMPILE_FLAGS -wd5046)
endif()
endif()
# ManagedStatic.cpp uses <pthread>.
[CMake] Use PRIVATE in target_link_libraries for executables We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
2017-12-05 21:49:56 +00:00
target_link_libraries(SupportTests PRIVATE LLVMTestingSupport ${LLVM_PTHREAD_LIB})
add_subdirectory(DynamicLibrary)