en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Modules/Inputs/warning-mismatch/module.modulemap#030d7d6d Reapply "Modules: Cache PCMs in memory and avoid a use-after-free"This reverts commit r298185, effectively reapplying r298165, after fixing thenew unit tests (PR32338). The memory buffer generator doesn't null-terminatethe MemoryBuffer it creates; this version of the commit informs getMemBufferabout that to avoid the assert.Original commit message follows:----Clang's internal build system for implicit modules uses lock files toensure that after a process writes a PCM it will read the same one backin (without contention from other -cc1 commands). Since PCMs are readfrom disk repeatedly while invalidating, building, and importing, thelock is not released quickly. Furthermore, the LockFileManager is notrobust in every environment. Other -cc1 commands can stall untiltimeout (after about eight minutes).This commit changes the lock file from being necessary for correctnessto a (possibly dubious) performance hack. The remaining benefit is toreduce duplicate work in competing -cc1 commands which depend on thesame module. Follow-up commits will change the internal build system tocontinue after a timeout, and reduce the timeout. Perhaps we shouldreconsider blocking at all.This also fixes a use-after-free, when one part of a compilationvalidates a PCM and starts using it, and another tries to swap out thePCM for something new.The PCMCache is a new type called MemoryBufferCache, which saves memorybuffers based on their filename. Its ownership is shared by theCompilerInstance and ModuleManager.- The ModuleManager stores PCMs there that it loads from disk, nevertouching 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, eachalready-loaded PCM is assumed to be valid, and is frozen to avoidthe use-after-free.- Any newly-built module is written directly to the cache to avoid theround-trip to the filesystem, making lock files unnecessary forcorrectness.Original patch by Manman Ren; most testcases by Adrian Prantl!llvm-svn: 298278 List of files: /llvm-project-15.0.7/clang/test/Modules/Inputs/warning-mismatch/module.modulemap Mon, 20 Mar 2017 17:58:26 +0000 Duncan P. N. Exon Smith <dexonsmith@apple.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/Modules/Inputs/warning-mismatch/module.modulemap#079c40e8 Modules: Cache PCMs in memory and avoid a use-after-freeClang's internal build system for implicit modules uses lock files toensure that after a process writes a PCM it will read the same one backin (without contention from other -cc1 commands). Since PCMs are readfrom disk repeatedly while invalidating, building, and importing, thelock is not released quickly. Furthermore, the LockFileManager is notrobust in every environment. Other -cc1 commands can stall untiltimeout (after about eight minutes).This commit changes the lock file from being necessary for correctnessto a (possibly dubious) performance hack. The remaining benefit is toreduce duplicate work in competing -cc1 commands which depend on thesame module. Follow-up commits will change the internal build system tocontinue after a timeout, and reduce the timeout. Perhaps we shouldreconsider blocking at all.This also fixes a use-after-free, when one part of a compilationvalidates a PCM and starts using it, and another tries to swap out thePCM for something new.The PCMCache is a new type called MemoryBufferCache, which saves memorybuffers based on their filename. Its ownership is shared by theCompilerInstance 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: 298165 List of files: /llvm-project-15.0.7/clang/test/Modules/Inputs/warning-mismatch/module.modulemap Fri, 17 Mar 2017 22:55:13 +0000 Duncan P. N. Exon Smith <dexonsmith@apple.com>