ilya-biryukov added a comment. In D69263#1717985 <https://reviews.llvm.org/D69263#1717985>, @hokein wrote:
> Thinking more about this -- we have a dynamic index (for all opened files) > which is overlaid on a static index (which is a background index in > open-source world), so for all affected files, they are either in > > 1. an open state -- we can rely on the dynamic index, I think it is safe to > assume that index always returns up-to-date results; Not sure that holds. What if the file in question is being rebuilt right now? We do not wait until all ASTs are built (and the dynamic index gets the new results). Open files actually pose an interesting problem: their contents do not correspond to the file contents on disk. We should choose which of those we update on rename: dirty buffers or file contents? (I believe we should do dirty buffers, but I believe @sammccall has the opposite opinion, so we should sync on this) > 2. a non-open state -- rely on the background index, however background index > has more chance to be stale (especially we don't detect file-change events at > the moment), we could do a range patch heuristically to mitigate this stale > issue. Failing that, we surface the error to users. To summarize, I think files can be stale in both cases and we should patch the ranges in both cases. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69263/new/ https://reviews.llvm.org/D69263 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
