Do not memory map the main file if the flag UserFilesAreVolatile is set to true in ASTUnit when calling FileSystem::getBufferForFile
Details
- Reviewers
ilya-biryukov nik klimek bkramer - Commits
- rG2ebe3a024056: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
rC334070: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
rL334070: [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnit
Diff Detail
Event Timeline
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)
This is the proper fix. When we get a buffer for main file we should use the UserFilesAreVolatile flag to specify if memory mapping needs to occur or not.
i think I can add a unit-test for it since we have the 'getBufferKind' method in MemoryBuffer.
That sounds good. Having a regression test that fails with descriptive messages in case anyone changes this would certainly be useful.
If that's not a lot of work, of course.
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.
unittests/Frontend/ASTUnitTest.cpp | ||
---|---|---|
21 | Macros are evil. Maybe use TEST_F, and make these members of the base class? |
Macros are evil. Maybe use TEST_F, and make these members of the base class?