llvm-project/clang/lib/Basic/CMakeLists.txt

103 lines
2.6 KiB
CMake
Raw Normal View History

set(LLVM_LINK_COMPONENTS
Core
MC
Support
)
find_first_existing_vc_file(llvm_vc "${LLVM_MAIN_SRC_DIR}")
find_first_existing_vc_file(clang_vc "${CLANG_SOURCE_DIR}")
# The VC revision include that we want to generate.
set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/SVNVersion.inc")
set(get_svn_script "${LLVM_CMAKE_PATH}/GetSVN.cmake")
if(DEFINED llvm_vc AND DEFINED clang_vc)
# Create custom target to generate the VC revision include.
add_custom_command(OUTPUT "${version_inc}"
DEPENDS "${llvm_vc}" "${clang_vc}" "${get_svn_script}"
COMMAND
${CMAKE_COMMAND} "-DFIRST_SOURCE_DIR=${LLVM_MAIN_SRC_DIR}"
"-DFIRST_NAME=LLVM"
"-DSECOND_SOURCE_DIR=${CLANG_SOURCE_DIR}"
"-DSECOND_NAME=SVN"
"-DHEADER_FILE=${version_inc}"
-P "${get_svn_script}")
# Mark the generated header as being generated.
set_source_files_properties("${version_inc}"
PROPERTIES GENERATED TRUE
HEADER_FILE_ONLY TRUE)
# Tell Version.cpp that it needs to build with -DHAVE_SVN_VERSION_INC.
set_source_files_properties(Version.cpp
PROPERTIES COMPILE_DEFINITIONS "HAVE_SVN_VERSION_INC")
else()
# Not producing a VC revision include.
set(version_inc)
# Being able to force-set the SVN revision in cases where it isn't available
# is useful for performance tracking, and matches compatibility from autoconf.
if(SVN_REVISION)
set_source_files_properties(Version.cpp
PROPERTIES COMPILE_DEFINITIONS "SVN_REVISION=\"${SVN_REVISION}\"")
endif()
endif()
add_clang_library(clangBasic
Attributes.cpp
Builtins.cpp
CharInfo.cpp
Cuda.cpp
Diagnostic.cpp
2010-11-19 05:19:52 +08:00
DiagnosticIDs.cpp
DiagnosticOptions.cpp
FileManager.cpp
FileSystemStatCache.cpp
IdentifierTable.cpp
LangOptions.cpp
Reapply "Modules: Cache PCMs in memory and avoid a use-after-free" This reverts commit r298185, effectively reapplying r298165, after fixing the new unit tests (PR32338). The memory buffer generator doesn't null-terminate the MemoryBuffer it creates; this version of the commit informs getMemBuffer about that to avoid the assert. Original commit message follows: ---- Clang's internal build system for implicit modules uses lock files to ensure that after a process writes a PCM it will read the same one back in (without contention from other -cc1 commands). Since PCMs are read from disk repeatedly while invalidating, building, and importing, the lock is not released quickly. Furthermore, the LockFileManager is not robust in every environment. Other -cc1 commands can stall until timeout (after about eight minutes). This commit changes the lock file from being necessary for correctness to a (possibly dubious) performance hack. The remaining benefit is to reduce duplicate work in competing -cc1 commands which depend on the same module. Follow-up commits will change the internal build system to continue after a timeout, and reduce the timeout. Perhaps we should reconsider blocking at all. This also fixes a use-after-free, when one part of a compilation validates a PCM and starts using it, and another tries to swap out the PCM for something new. The PCMCache is a new type called MemoryBufferCache, which saves memory buffers based on their filename. Its ownership is shared by the CompilerInstance and ModuleManager. - The ModuleManager stores PCMs there that it loads from disk, never touching the disk if the cache is hot. - When modules fail to validate, they're removed from the cache. - When a CompilerInstance is spawned to build a new module, each already-loaded PCM is assumed to be valid, and is frozen to avoid the use-after-free. - Any newly-built module is written directly to the cache to avoid the round-trip to the filesystem, making lock files unnecessary for correctness. Original patch by Manman Ren; most testcases by Adrian Prantl! llvm-svn: 298278
2017-03-21 01:58:26 +08:00
MemoryBufferCache.cpp
Module.cpp
ObjCRuntime.cpp
OpenMPKinds.cpp
OperatorPrecedence.cpp
SanitizerBlacklist.cpp
SanitizerSpecialCaseList.cpp
Sanitizers.cpp
SourceLocation.cpp
SourceManager.cpp
TargetInfo.cpp
Targets.cpp
Targets/AArch64.cpp
Targets/AMDGPU.cpp
Targets/ARM.cpp
Targets/AVR.cpp
Targets/BPF.cpp
Targets/Hexagon.cpp
Targets/Lanai.cpp
Targets/Le64.cpp
Targets/MSP430.cpp
Targets/Mips.cpp
Targets/NVPTX.cpp
Targets/Nios2.cpp
Targets/OSTargets.cpp
Targets/PNaCl.cpp
Targets/PPC.cpp
Targets/RISCV.cpp
Targets/SPIR.cpp
Targets/Sparc.cpp
Targets/SystemZ.cpp
Targets/TCE.cpp
Targets/WebAssembly.cpp
Targets/X86.cpp
Targets/XCore.cpp
TokenKinds.cpp
Version.cpp
Implement a new 'availability' attribute, that allows one to specify which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. llvm-svn: 128127
2011-03-23 08:50:03 +08:00
VersionTuple.cpp
VirtualFileSystem.cpp
Warnings.cpp
XRayLists.cpp
${version_inc}
)