766a08df12
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
20 lines
310 B
CMake
20 lines
310 B
CMake
set(LLVM_LINK_COMPONENTS
|
|
BitReader
|
|
BitstreamReader
|
|
Support
|
|
)
|
|
|
|
add_clang_unittest(SerializationTests
|
|
InMemoryModuleCacheTest.cpp
|
|
ModuleCacheTest.cpp
|
|
)
|
|
|
|
clang_target_link_libraries(SerializationTests
|
|
PRIVATE
|
|
clangAST
|
|
clangBasic
|
|
clangFrontend
|
|
clangLex
|
|
clangSema
|
|
clangSerialization
|
|
)
|