-
-
Notifications
You must be signed in to change notification settings - Fork 369
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
Support structured diagnostics 2 #4433
base: master
Are you sure you want to change the base?
Support structured diagnostics 2 #4433
Conversation
All failures in the jobs of e651d41 seem to be spurious (except for the stylish-haskell formatting failure). |
I think the remaining failures are not caused by this PR. Are these kinds of spurious failures common in HLS? Also, I would really like to get this merged before the next release, because I want to develop a VS Code extension which uses these diagnostic numbers. |
Yes, they unfortunately are |
Some errors in ghc |
You're right. Can anyone give me some tips on how to profile HLS to see where these timeouts are coming from? |
@noughtmare Profiling is likely not necessary, I think the tests are waiting for an LSP message that never arrives, and then just wait for 60s and time out. Use |
Ah, I was thinking there was some inefficiency somewhere that only GHC 9.6 and later could properly optimize. However, I think you're suggesting an alternative explanation: that one of the conditional CPP blocks contains an actual correctness issue. Perhaps I could just visually inspect those first; I don't think that would be that much work. Edit: no obvious loops or anything, so perhaps some tracing would indeed be better. |
I've decided to make the tests ignore all error codes on GHC 9.4. I think some errors already have codes in 9.4, so we could do a bit more, but I don't think it is worth the effort. |
The remaining MacOS failure seems like a compiler bug. The linker is throwing an error. Edit: https://gitlab.haskell.org/ghc/ghc/-/issues/24648 Adding the compiler flag |
@fendor do you think we could try setting the |
Oh, I see we already have that exact workaround in some places. I'll just copy that to the hlint plugin. |
Yay, it has finally passed CI! Should I squash the commits? I'm not sure what to write in the message as I don't really know the details of what exactly Dylan did. |
7773572
to
469d8a7
Compare
We're leaving the TODOs for either later in this PR or in another PR
af550e3
to
f4d5c24
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me long enough, but I am happy with the PR now.
I still have to address my own comments, and likely I have to revert any changes to the plugins and split these commits off into a separate PR.
@noughtmare Is there anythign else you need or want from this PR? |
I personally just wanted access to the diagnostic codes. So I'm more than satisfied! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Just two questions
Implement 'rangesOverlap' function which checks whether two 'Range's overlap in any way. Implement two new plugin utility functions which allow to conveniently get all currently displayed diagnostics for a given 'Range'.
Add compatibility module for GHC's structured error messages. Introduce 'Prism's and 'Lens's to easily access nested structures. Expand documentation for 'StructuredMessage'
Fixes haskell#4440 Fixes test for disabling deferred-type-errors.
Co-authored-by: Mergify <37929162+mergify[bot]@users.noreply.github.com>
* new tests * change codeAction title * more tests and docs --------- Co-authored-by: fendor <[email protected]>
Allows HLS to 'Goto Definition' for Note references.
6b1f66e
to
95f65d9
Compare
c1513bd
to
371896a
Compare
This is my attempt at finishing the work of @dylan-thinnes on !4311.
Addresses #2014
Should hopefully enable #3246
These are two things Dylan listed as work for future PRs:
Some future work discovered in reviews of this PR:
requireDiagnostic
could take a more structured error code query type as argument. See Support structured diagnostics 2 #4433 (comment)requireDiagnostics
and related functions use explicit error codes if possible