llvm-project/clang/unittests/Serialization/CMakeLists.txt

set(LLVM_LINK_COMPONENTS
  BitReader
  BitstreamReader
  Support
  )

add_clang_unittest(SerializationTests
  InMemoryModuleCacheTest.cpp
  ModuleCacheTest.cpp
  SourceLocationEncodingTest.cpp
  )

clang_target_link_libraries(SerializationTests
  PRIVATE
  clangAST
  clangBasic
  clangFrontend
  clangLex
  clangSema
  clangSerialization
  )
Modules: Rename MemoryBufferCache to InMemoryModuleCache Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777 2019-03-10 01:33:56 +08:00			`set(LLVM_LINK_COMPONENTS`
			`BitReader`
[Bitcode] Move Bitstream to a separate library This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091 2019-07-04 06:40:07 +08:00			`BitstreamReader`
Modules: Rename MemoryBufferCache to InMemoryModuleCache Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777 2019-03-10 01:33:56 +08:00			`Support`
			`)`

			`add_clang_unittest(SerializationTests`
			`InMemoryModuleCacheTest.cpp`
[Frontend] Only compile modules if not already finalized It was possible to re-add a module to a shared in-memory module cache when search paths are changed. This can eventually cause a crash if the original module is referenced after this occurs. 1. Module A depends on B 2. B exists in two paths C and D 3. First run only has C on the search path, finds A and B and loads them 4. Second run adds D to the front of the search path. A is loaded and contains a reference to the already compiled module from C. But searching finds the module from D instead, causing a mismatch 5. B and the modules that depend on it are considered out of date and thus rebuilt 6. The recompiled module A is added to the in-memory cache, freeing the previously inserted one This can never occur from a regular clang process, but is very easy to do through the API - whether through the use of a shared case or just running multiple compilations from a single `CompilerInstance`. Update the compilation to return early if a module is already finalized so that the pre-condition in the in-memory module cache holds. Resolves rdar://78180255 Differential Revision: https://reviews.llvm.org/D105328 2021-07-16 09:24:09 +08:00			`ModuleCacheTest.cpp`
[Serialization] Delta-encode consecutive SourceLocations in TypeLoc Much of the size of PCH/PCM files comes from stored SourceLocations. These are encoded using (almost) their raw value, VBR-encoded. Absolute SourceLocations can be relatively large numbers, so this commonly takes 20-30 bits per location. We can reduce this by exploiting redundancy: many "nearby" SourceLocations are stored differing only slightly and can be delta-encoded. Randam-access loading of AST nodes constrains how long these sequences can be, but we can do it at least within a node that always gets deserialized as an atomic unit. TypeLoc is implemented in this patch as it's a relatively small change that shows most of the API. This saves ~3.5% of PCH size, I have local changes applying this technique further that save another 3%, I think it's possible to get to 10% total. Differential Revision: https://reviews.llvm.org/D125403 2022-05-11 21:42:31 +08:00			`SourceLocationEncodingTest.cpp`
Modules: Rename MemoryBufferCache to InMemoryModuleCache Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777 2019-03-10 01:33:56 +08:00			`)`

cmake: Add CLANG_LINK_CLANG_DYLIB option Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092 2019-07-04 06:45:55 +08:00			`clang_target_link_libraries(SerializationTests`
Modules: Rename MemoryBufferCache to InMemoryModuleCache Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777 2019-03-10 01:33:56 +08:00			`PRIVATE`
			`clangAST`
			`clangBasic`
[Frontend] Only compile modules if not already finalized It was possible to re-add a module to a shared in-memory module cache when search paths are changed. This can eventually cause a crash if the original module is referenced after this occurs. 1. Module A depends on B 2. B exists in two paths C and D 3. First run only has C on the search path, finds A and B and loads them 4. Second run adds D to the front of the search path. A is loaded and contains a reference to the already compiled module from C. But searching finds the module from D instead, causing a mismatch 5. B and the modules that depend on it are considered out of date and thus rebuilt 6. The recompiled module A is added to the in-memory cache, freeing the previously inserted one This can never occur from a regular clang process, but is very easy to do through the API - whether through the use of a shared case or just running multiple compilations from a single `CompilerInstance`. Update the compilation to return early if a module is already finalized so that the pre-condition in the in-memory module cache holds. Resolves rdar://78180255 Differential Revision: https://reviews.llvm.org/D105328 2021-07-16 09:24:09 +08:00			`clangFrontend`
Modules: Rename MemoryBufferCache to InMemoryModuleCache Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to Serialization. Another patch will start using it to manage module build more explicitly, but this is split out because it's mostly mechanical. Because of the move to Serialization we can no longer abuse the Preprocessor to forward it to the ASTReader. Besides the rename and file move, that means Preprocessor::Preprocessor has one fewer parameter and ASTReader::ASTReader has one more. llvm-svn: 355777 2019-03-10 01:33:56 +08:00			`clangLex`
			`clangSema`
			`clangSerialization`
			`)`