- sometimes an exception could be wrapped in TestAssertionError by Logger - expect both
- avoid data race when thread 1 does "progress.cancel(); save exception" and the other thread does "progress.checkCanceled(); catch (PCE) { get saved exception }"
- unify saved exception storage in the DPI
GitOrigin-RevId: cc960addac3c9eb71522fc6c63edf8248c90ca71
do not disable ChangeLocalityDetector produced scope when the reference was changed in languages other than Java/Kotlin, because the rules might be different there. Instead, move that logic inside the java/kotlin ChangeLocalityDetectors
GitOrigin-RevId: 4aafa966186fe038c25e0a2512c80ba1b1d93eeb
Rework the "when to remove highlighters for invalid PSI" heuristic.
Instead of removing them immediately for dirty document regions, recycle them all, in the hope that some languages with poor incremental reparse support will reuse them, event in the dirty regions, e.g. during massive refactorings.
If after some short time (500ms currently, highlighting.delay.invalid.psi.info.kill.ms) these invalid psi highlighters are not reclaimed, kill them to improve responsiveness of removing outdated infos.
GitOrigin-RevId: b5b52c72d7fac0eaab18a5a696b32ae74096ff89
, to fix problems when many file-level infos with always changing descriptions are generated by one tool, e.g. when LargeFileAnnotator generates a different file-level highlighter on every typing
GitOrigin-RevId: f68527d9f3767535247b3680eaa8b26892f940bf
rework the HighlightInfoUpdater to avoid obsolete error elements stuck in the markup
The problem was in the several highlighting sessions overlapping each other when the one session was canceled but still lingered on while the other started and progressed far enough.
The two sessions called setHighlightersInRange() in HighlightInfoUpdater in reentrant fashion which could lead to some highlighters to be forgotten by HighlightInfoUpdater internal data structures. The fix is to refactor HighlightInfoUpdater to guarantee that the highlighters registered there are always contained in the markup and vice versa.
Several testcases added to DaemonRespondToChangesTest where the test invokes typing, then waits for the daemon to start, then proceed to another typing, effectively canceling the daemon process very frequently to induce the session overlappings and then checking that no error element highlighters are left in the markup
GitOrigin-RevId: 9b72068d71b28d940c3e9fdb98574c78e4776800
- ensure HighlighterRecycler disposes RangeHighlighter only when it removed from HighlightInfoUpdaterImpl data structures
- for that, make HighlighterRecycler usages more structural
- In order to avoid flickering of invalid PSI elements highlighting (caused by poor PSI incremental reparse), do not remove highlighting of invalid PSI elements right away, but recycle RH instead, until the GHP/LIP finished
- After that, to avoid annoying pause removing highlighting of invalid PSI elements on typing, caused by increased latency due to RH recycling above, introduce new heuristic:
1) when the document change was near these PSI elements, remove the corresponding highlighting immediately: it most probably was typing over these PSI elements, the chance they'll survive is small
2) when the document change was outside these PSI elements, e.g. in the other corner of the file, recycle these RH until the GHP ended, since these probably were artifacts of poor incremental reparse, chances are high these RH will reappear at the same place
- to get the "document dirty range", add document listener to FileStatusMap which combines/maintains document events until the highlighting is done
GitOrigin-RevId: 0961deb12999760a7bce0a2322c9d535feb5408f
