Community
Participate
Working Groups
Currently the SelectionListenerWithASTManager is designed such that if the selection changes inside of a single editor then the previous selection calculation, if still running, will be canceled. This is to save on unnecessarily type building. If the user switches selection between editors though the selection calculation is not canceled. The end effect of this is that if the user switches selection between multiple editors in quick succession the type hierarchy for all of those selections will be calculating in parallel using unnecessary system resources. The fix is to cancel all selection calculations on a selection change whether they be in the same editor or a different editor from the new selection.
Created attachment 195848 [details] Fix Patch This patch does three things. It updates the SelectionListenerWithASTManager so that it will cancel all selection jobs if a the selection changes instead of just the one in the current editor. The second thing it does is update JavaScriptUnitResolver to check its canceled status more often. More specifically now it will check it before and after every call to one of the #accept methods. Lastly the CancelableProblemFactory is updated to throw an OperationCanceledException rather then an AbortCompilation exception so that the exception gets handled by the correct catch blocks. As an AbortCompilation exception it would be logged, but there is no need to log this because it is a legal state to get into.
Although IProgressMonitor#worked() only requires a non-negative number, I'm not comfortable with it being called with 0.
Created attachment 197493 [details] Fix Patch - Update 1 Same solution as my first patch except a new function is created to check the cancelled state of the monitor so 0 is no longer passed to #worked().
Approved and committed.
