[#2143] Run aggregation pass only once in following passes
Motivation and Context
Problem
Aggregation pass is slow and we run it in the following passes
n + 1 times where n is the number of module entrypoints. We should
reduce this number somehow.
Solution
Generate an entrypoint that refers to the all module entrypoints.
It reduced the number of cycles in following_passes_diagnostics from
5.7G to 4.1G. For more information read the comments.
Related issues
Resolves a part of #2143 .
✅ Checklist for the LIGO Language Server
- I checked whether I need to update the
README.mdfile for the plugin and did so if necessary:-
If I implemented a new LSP request, I added it to the list of supported features that may be disabled -
If I implemented a new LSP method, I added it to the list of supported functionality
-
-
I checked that my changes work in Emacs, Vim, and Visual Studio Code -
(Before merging) The commit history is squashed and prettified, and follows the Serokell commit policy, or the MR is set to squash the commits
Description
Component
-
compiler -
website -
webide -
vscode-plugin -
debugger
Types of changes
-
Bug fix (non-breaking change which fixes an issue) -
New feature (non-breaking change which adds functionality) -
Breaking change (fix or feature that would cause existing functionality to not work as expected) -
Performance improvement (non-breaking change that improves performance) -
None (change with no changelog)
Changelog
The LSP should now take less time between keystrokes.
This is done by running aggregation pass only once per doc processing.
Checklist:
-
Changes follow the existing coding style (use dune @fmtto check). -
Tests for the changes have been added (for bug fixes / feature). -
Documentation has been updated. -
Changelog description has been added (if appropriate). -
Start titles under ## Changelogsection with #### (if appropriate). -
There is no image or uploaded file in changelog -
Examples in changed behaviour have been added to the changelog (for breaking change / feature).