forked from haskell/haskell-language-server
-
Notifications
You must be signed in to change notification settings - Fork 0
Batch load multi read #17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
soulomoon
wants to merge
112
commits into
master
Choose a base branch
from
batch-load-multi-read
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… them to improve performance fix haskell#4381
…p error loading and cradle files
ba7379b
to
79a43a0
Compare
Renames getOptions to getOptionsWorker for clarity Removes redundant getOptionsLoop function Ensures session loading is called under the same `Action` context
This closes haskell#4648. When adding constraint to a context which is followed by a comment, such as: ``` foo :: (Monad m) => -- | This is a comment m () ``` The comment annotation is anchored to the previous token, which is `=>` in this context. If we add a new constraint in the context, the newly generated content goes beyond the anchor and, depending on GHC version, or ghc-exactprint (the reason is not fully understood), the comment is printed BEFORE the new constraint, leading to invalid syntax, such as `(Monad m -- | This is a comment , Applicative m =>)` This commit moves all the comment of the block at the end of the block using the `followingComments` of `EpAnnComments`. It seems super adhoc, but actually, consider the following example: ```haskell bar :: -- BEFORE {- yoto -} (Monad m {- yiti -}){- yutu -} => {- yete -} -- Trailing -- After m () ``` Comment `BEFORE` and `yoto` are attached to the previous block. Comment `yiti` is attached to `Monad m`. The comments `yiti`, `yutu`, `yete`, `Trailing` and `After` are all attached to this block and will hence be moved after the block. However this is not an easy task, all the associated comments should be moved by the relevant offset. TODO: do that instead.
* hls-cabal-plugin: Fix cabal-add bound (haskell#4642) * Update haskell-language-server.cabal --------- Co-authored-by: fendor <[email protected]>
* Use hie-bios 0.16 * Strip RTS and verbosity flags after -unit flag parsing * Add RTS flags to test cases to make sure they are stripped out * pre-commit hook --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Show LaTeX math expressions in haddockToMarkdown - Replace fallback messages with raw LaTeX math expressions using $...$ and $$...$$. - This lets editors display the original math content even if they don't render LaTeX. - No sanitization is performed, raw LaTeX is output as-is. * Do backticks for inline math and fenced latex blocks for math blocks
…l#4664) * Use structured diagnostics for type wildcard fill suggestions * Fix formatting * Fix compilation error for GHC-9.10+ for hls-refactor-plugin
* Avoid unnecessary recompilation due to -haddock Due to unprincipled adding and removing the `-haddock` flag during compilation and recompilation checking, we were performing more work than necessary. We avoid this by compiling everything with `-haddock` by default. This is safe nowadays, we have essentially been doing this for many releases, and know this is fine. For the occasion where we actually want to parse without the `-haddock` flag, we keep explicitly disabling it. We enable `-haddock` flag during session loading, since we already perform a number of DynFlags tweaks. This behaviour is dependent on the `OptHaddockParse` opton, which can, currently, only be modified at compile-time. * Fix windows test failure --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
While removing references to GHC 9.4, I realized that some parts of HLS are referring to even older versions of GHC. For example, `hie-compat` is a compatibility library backporting support of Haskell IDE Engine (HIE) features to older versions of GHC. Since GHC 9.2, `hie-compat` only re-exported definitions already present in the `ghc` library, and so, is essentially obsolete. FYI: We still have `hie-compat` in the dependency graph, because some libraries (e.g., `hiedb`) are using it.
* [fix] don't bake ide state mvar into setup and getIdeState This is the right thing to do because othewise it is not possible to create new ideStates in a single instance of the executable. This will be useful if the hls executable is supposed to talk to multiple clients and lives beyond a single client disconnecting. * [fix] don't throw hard errors when no shutdown message is handled Previously, when there was no shutdown message by a client and the client disconnected, resulting in the handlers to be GC'd the race that was supposed to free resources for the HieDB & co. would throw a hard error talking about the MVar being unreachable. We would like to instead finish gracefully because finishing the race as soon as the MVar was GC'd is the right thing to do anyway. * [chore] apply suggestions from code review by @fendor * [chore] apply suggestions from code review by @fendor --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
For diagnostics complaining about the current module being unknown, we now offer code actions to add the module to any possible field in the responsible cabal file. Additionally, refactor the cabal-plugin into smaller modules and refactor the add-package feature to have some shared functions to be used for both add-package and add-module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.