Selective reference resolving part1 #2764
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces selective resolving of references (by module). More precisely, only references of modules referencing a module that gets parsed are resolved.
To achieve this, I had to pull the store the unresolved declarations outside of the
DeclarationFinder
; they now live on theModuleStates
in a new collection separate from the real declarations. This has the added benefit that theDeclaratioFinder
seen by the inspections now really see the undeclared declarations in theDeclarationFinder
.Moreover, I had to change the clean up of references to only remove references from modules whose references get resolved again.
After the changes, the reparsing time in my test project dropped from 25s to 17s when there are no changes of the code at all and to 9s if there are minor changes.
This is only part 1 and not the full story because there are still some open points.
The compilation passes, namely the
TypeHierarchyPass
and theTypeAnnotationPass
still run on all modules. (They do not add duplicates, by design.)We do not clean up properly the declarations in the modules that do not get reparsed, namely the supertypes and subtypes added in the
TypeHierarchyPass
do not get cleaned up. (If an implemented interface gets reparsed, e.g. because the line spacing changed, the existing supertype declaration will be out of date after the reparse. )