llvm-project/llvm/unittests/Support/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

114 lines
2.9 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
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-22 06:36:31 +08:00
DJBTest.cpp
EndianStreamTest.cpp
EndianTest.cpp
ErrnoTest.cpp
ErrorOrTest.cpp
ErrorTest.cpp
FileCheckTest.cpp
FileCollectorTest.cpp
FileOutputBufferTest.cpp
FileUtilitiesTest.cpp
FormatVariadicTest.cpp
GlobPatternTest.cpp
Host.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
ParallelTest.cpp
Path.cpp
ProcessTest.cpp
ProgramTest.cpp
RegexTest.cpp
ReverseIterationTest.cpp
ReplaceFileTest.cpp
ScaledNumberTest.cpp
SourceMgrTest.cpp
SpecialCaseListTest.cpp
StringPool.cpp
SwapByteOrderTest.cpp
SymbolRemappingReaderTest.cpp
TarWriterTest.cpp
TargetParserTest.cpp
TaskQueueTest.cpp
ThreadLocalTest.cpp
ThreadPool.cpp
Threading.cpp
TimerTest.cpp
TypeNameTest.cpp
TypeTraitsTest.cpp
TrailingObjectsTest.cpp
TrigramIndexTest.cpp
UnicodeTest.cpp
VersionTupleTest.cpp
VirtualFileSystemTest.cpp
YAMLIOTest.cpp
YAMLParserTest.cpp
2012-09-15 07:36:56 +08:00
formatted_raw_ostream_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-06 05:49:56 +08:00
target_link_libraries(SupportTests PRIVATE LLVMTestingSupport ${LLVM_PTHREAD_LIB})
add_subdirectory(DynamicLibrary)