The repro involves:
- Multiple header files and a source file that includes them. (All same TU. Also impacts other TUs that reference the same file as edited.)
- Having multiple files from the same TU open simultaneously (split view or dragged out into separate windows).
- A non-trivial TU (takes a bit of time to finish an IntelliSense pass)
- Multiple edits to the same header file.
Seeing: didChange processing will block, stuck behind an IntelliSense update. That IntelliSense update with run redundantly (forced reparse) for each visible open source/header in the same TU. Only after the TU updates are all completed will the next didChange be processed. This leads to the extension falling behind on processing edits.
The root cause involves a call to contains_source in didChange. Since contains_sources involves the same lock as other IntelliSense operations, if one happens to be in progress when a didChange occurs, it will wait (at the same priority as other request).
The call to contains_source appears to be a work-around for a 'stale IntelliSense' issue. It's a bit heavy-handed as a work-around, forcing (redundant) reparsing for updates of each impacted visible file.
A proper fix would seem to involve fixing the root cause this works-around - stale squiggles in other files in a TU, after editing. For files in the same TU not updating properly, the issue may be (appears to be) related to IntelliSense calls (such as for signature help and reference highlighting), which get processed between(?) the edit and the IntelliSense update.
The repro involves:
Seeing:
didChangeprocessing will block, stuck behind an IntelliSense update. That IntelliSense update with run redundantly (forced reparse) for each visible open source/header in the same TU. Only after the TU updates are all completed will the nextdidChangebe processed. This leads to the extension falling behind on processing edits.The root cause involves a call to
contains_sourceindidChange. Sincecontains_sourcesinvolves the same lock as other IntelliSense operations, if one happens to be in progress when adidChangeoccurs, it will wait (at the same priority as other request).The call to
contains_sourceappears to be a work-around for a 'stale IntelliSense' issue. It's a bit heavy-handed as a work-around, forcing (redundant) reparsing for updates of each impacted visible file.A proper fix would seem to involve fixing the root cause this works-around - stale squiggles in other files in a TU, after editing. For files in the same TU not updating properly, the issue may be (appears to be) related to IntelliSense calls (such as for signature help and reference highlighting), which get processed between(?) the edit and the IntelliSense update.