From 01c0c3c9244df0c01fdd294a2dc466bb5f6d10c4 Mon Sep 17 00:00:00 2001 From: Nikolay Krasko Date: Mon, 22 Apr 2019 14:39:20 +0300 Subject: [PATCH] Addition note about intention and quick-fixes execution in UI thread --- docs/intentions_inspections_quickfixes.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/intentions_inspections_quickfixes.md b/docs/intentions_inspections_quickfixes.md index ef54574bacc..a090f75dc2b 100644 --- a/docs/intentions_inspections_quickfixes.md +++ b/docs/intentions_inspections_quickfixes.md @@ -39,6 +39,11 @@ function when descriptor is absent. invalidated by the moment of the actual quick fix execution. Avoid the code that can throw exceptions because of that. Re-checks with early exit from the quick fix can be used to workaround it. +- Intentions and quick fixes execution happens in the UI thread so do not call long operations such as usages search or resolve to avoid +freezes. `PSI` elements obtained from resolve during the applicability check can be stored in `SmartPsiElementPointer` for the postponed +modification in quick-fixes. All complex searches should be executed in a background thread under a progress indicator. Some tests +already assert that resolve operations are not called from UI thread while applying fixes. + - There shouldn't be PSI elements stored in QuickFix classes (`val psi: PsiElement`) as such elements might be invalidated and can lead to memory leaks. Smart pointer (check `SmartPsiElementPointer` class and `createSmartPointer()` function) can be used when such storage is absolutely necessary.