Do not memory map the main file if the flag UserFilesAreVolatile is set to true in ASTUnit when calling FileSystem::getBufferForFile
ilya-biryukov nik klimek bkramer
- rC334070: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
rL334070: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
rG2ebe3a024056: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
The precise path which leads here is yet unclear for me (it requires much more time to research) but changing this specific default value to true fixes main file from being memory mapped and therefore being blocked (on Windows)
I assume it comes from FileManager::getBufferForFile(StringRef Filename) but not sure about prior events causing it.
Usually the wrong behavior can be encountered via reparsing the file.
It's a very subtle change and it isn't clear if that's the right thing to do without understanding the problem that we're trying to solve.
Could you please elaborate on the problem?
accidental memory mapping for main file which sometimes happens through FileSystem::getBufferForFile
Why is memory mapping considered accidental and what problems does it cause?
Memory mapping locks the file on Windows. That means that in the addressed case it locks main file which we are editing. After that happens many tools struggle to do something with this file, for example git.
It's the quickest solution, probably not the best. Better one would introduce isVolatile parameter in FileSystem::getBufferForFile which should be set to true somewhere (I didn't have time to search for the specific location yet)
I could not properly test getMainBufferWithPrecompiledPreamble because it's private and requires some extra context to be called.
But there's another getBufferForFile call in ASTUnit which has similar symptoms and might cause wrong mmap behavior. I've also appended it with the same parameter 'UserFilesAreVolatile' and added unit-test for it.