Skip to content

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
wants to merge 112 commits into
base: master
Choose a base branch
from
Open

Batch load multi read #17

wants to merge 112 commits into from

Conversation

soulomoon
Copy link
Owner

No description provided.

@soulomoon soulomoon force-pushed the batch-load-multi-read branch from ba7379b to 79a43a0 Compare November 9, 2024 12:06
guibou and others added 30 commits July 8, 2025 09:22
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.