-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Fix sourcekitd persistent file-locks on Windows #75406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix sourcekitd persistent file-locks on Windows #75406
Conversation
ed35105
to
268b2ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable to me - just because some platforms allow I/O to files which are backing MMIO doesn't mean we should assume that all platforms do. I wonder if there is an explicit guarantee that MMIO backing is preserved under modification (feels like it would have to disable CoW for this to work?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm excited for this fix, but I wonder if there's a better way to pipe the flag through
268b2ff
to
a22419f
Compare
cc @ahoppen: would appreciate any thoughts you have here! |
I would prefer to not have a distinction between SourceKit and a compilation here. I imagine that you could run into a similar issue during compilation if the source file takes a considerable amount of time to compile. Could we instead check if the current platform is Windows and, if so, always pass |
I don't think that's a good idea. This is going to increase memory pressure on windows, which already has a slower build rate due to the fork exec heavy nature of the swift compiler (clang does an in process cc1). Not being able to save on top of the file during compilation is fine (and expected behavior on windows). When the file is being opened by LSP, it doesn't get closed again, which prevents subsequent writes indefinitely. |
Can we limit this to Windows only then? And possibly also rename
Just to be clear, when LSP opens a file we create an in-memory buffer. If this fixes the issue then it's the secondary files in the same module that are being opened. Also seems like there's some underlying bug here somewhere too, since I wouldn't expect
|
I'm okay with scoping this to Windows. I don't remember if POSIX guarantees that the mmap I/O backing store is modifiable when mapped.
Hmm, with mmap'ed data, it needs to remain mapped right? Or is the data processed and then the buffer dropped? |
I would naively expect the latter, but it's quite possible we're holding the files open while the ASTContext is alive (and maybe we do actually need to). That shouldn't be indefinitely, could be a somewhat lengthy period though. |
I would expect it to be kept while the |
I'm happy to scope this down to Windows only and to rename The buffer is loaded and owned by That said, avoiding mmapping source files opened by sourcekitd on Windows is desirable regardless of the length of time they are held open, as even transient save failures are a frustrating experience. |
eb4c9a6
to
2a2ac18
Compare
2a2ac18
to
221c703
Compare
@swift-ci please test |
I think that this is ready to merge, going to merge to improve the windows state. |
Fixes swiftlang/sourcekit-lsp#644
During semantic analysis,
swift::vfs::getFileOrSTDIN
opens files with a defaultIsVolatile=false
arg, which makes its way down throughMemoryBuffer::getOpenFile
, toshouldUseMmap
. If this function's heuristics returned true, the file would be mmapped by sourcekitd and then could no longer be saved in an open editor until sourcekitd was killed. One of the heuristics used is a file-size check to avoid memory-mapping small files, and so this issue would only trigger on large source files.This patch propagates
LangOpts.DiagnosticsEditorMode
intoSourceManager
as a neweditorMode
boolean, that is now passed as theIsVolatile
parameter toswift::vfs::getFileOrSTDIN
, avoiding memory mapping files when the compiler is being invoked by sourcekitd.Stack trace for the curious: