Skip to content
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

Open
wants to merge 58 commits into
base: master
Choose a base branch
from

Conversation

noughtmare
Copy link
Contributor

@noughtmare noughtmare commented Oct 17, 2024

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:

  • Replacing regexes with structured diagnostic checks
  • Improve typing so that it can be known that an error has a structured diagnostic, instead of defaulting to Maybe

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)
  • The HTTP work should be un-reverted in a future PR: 1bc221c
  • Check that tests using requireDiagnostics and related functions use explicit error codes if possible

@noughtmare
Copy link
Contributor Author

All failures in the jobs of e651d41 seem to be spurious (except for the stylish-haskell formatting failure).

@noughtmare
Copy link
Contributor Author

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.

@fendor
Copy link
Collaborator

fendor commented Oct 18, 2024

Are these kinds of spurious failures common in HLS?

Yes, they unfortunately are

@fendor
Copy link
Collaborator

fendor commented Oct 18, 2024

Some errors in ghc 9.4 seem to be genuine, though. Many tests are seemingly time outing for some reason.

@noughtmare
Copy link
Contributor Author

You're right. Can anyone give me some tips on how to profile HLS to see where these timeouts are coming from?

@fendor
Copy link
Collaborator

fendor commented Oct 18, 2024

@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 HLS_TEST_LOG_STDERR=1 cabal test ... and TASTY_PATTERN to run a specific test with all HLS logging enabled.
Printf debugging also works quite well to figure out where the tests gets stuck.
To get the raw LSP messages, you can use LSP_TEST_LOG_MESSAGES=1 or LSP_TEST_LOG_STDERR=1 (they do the same thign)

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 18, 2024

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.

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 22, 2024

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.

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 23, 2024

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 -ld_classic might be a workaround.

@noughtmare
Copy link
Contributor Author

@fendor do you think we could try setting the -ld_classic flag? If so, where should I put it?

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 23, 2024

Oh, I see we already have that exact workaround in some places. I'll just copy that to the hlint plugin.

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 23, 2024

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.

@fendor
Copy link
Collaborator

fendor commented Oct 24, 2024

I think the linked code is wrong, the benchmark isn't executed on each PR, see https://github.com/haskell/haskell-language-server/actions/runs/11481138334/job/31951108378?pr=4433, but only nightly or on demand. So good catch :)

@noughtmare noughtmare mentioned this pull request Oct 24, 2024
@soulomoon soulomoon added the performance Issues about memory consumption, responsiveness, etc. label Oct 25, 2024
@soulomoon
Copy link
Collaborator

soulomoon commented Oct 25, 2024

We need performance label to run the benchmark, see #4271.
Now it runs, the result seems good for the benchmark

Copy link
Collaborator

@soulomoon soulomoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work, just a few neatpicks and a question

hls-test-utils/src/Development/IDE/Test.hs Outdated Show resolved Hide resolved
plugins/hls-refactor-plugin/test/Main.hs Outdated Show resolved Hide resolved
@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 26, 2024

Interesting, it seems the stack build converts more warnings to errors than the cabal build.

@wz1000
Copy link
Collaborator

wz1000 commented Oct 30, 2024

I'm a bit confused, I see we now store the structured diagnostics for warnings from the typechecker in tmrWarnings, but where do other structured diagnostics from other places and typechecker errors go? It seems like we convert them to LSP diagnostics and don't have the structured value available?

@noughtmare
Copy link
Contributor Author

noughtmare commented Oct 30, 2024

@wz1000 I think I removed that in 0776c65 (in response to #4433 (comment)), because we don't use it anywhere else yet and it would be very simple to add back when we do actually need it.

@noughtmare
Copy link
Contributor Author

Thank you for the reviews! I hope I have addressed all feedback appropriately. Is there anything more I can do to speed up the process of merging this?

@fendor
Copy link
Collaborator

fendor commented Nov 2, 2024

Probably not, except for regularly pinging on this thread to make sure we get enough reviews, soon :) We need two approvals, considering the importance of this change, we shouldn't rush merging it without proper review time.

However, I hope we can merge it within the next two weeks (hopefully a pessimistic timeframe, but I don't really want to give any time estimate at all :D ).

@fendor fendor added the status: needs review This PR is ready for review label Nov 2, 2024
Copy link
Collaborator

@soulomoon soulomoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question, other places look good to me.

fdLspDiagnostic =
lspDiag
& attachReason (fmap (diagnosticReason . errMsgDiagnostic) mbOrigMsg)
& setGhcCode mbOrigMsg
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So all the MsgEnvelope are converted to FileDiagnostic through this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, yes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually looking at when this function is called with a Just and couldn't easily find anything, because there are so many callers that pass along a value for which you then have to transitively search.

Copy link
Contributor Author

@noughtmare noughtmare Nov 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

plugins/hls-refactor-plugin/test/Main.hs Outdated Show resolved Hide resolved
@soulomoon soulomoon self-requested a review November 4, 2024 16:51
@noughtmare
Copy link
Contributor Author

regularly pinging

ping

@fendor
Copy link
Collaborator

fendor commented Nov 19, 2024

In the last HLS meeting, we discussed this PR and what we want from it, for transparency, these are the notes https://docs.google.com/document/d/1zqRhA3uoiYgA_Q8eDpIEG0OiFcofGqkVP7N4ODDmikM/edit?tab=t.0

In short, I will review soon and try to make use of the structured diagnostics in 1 or 2 of the plugins, to demonstrate how we can use them in the future and to make sure this PR takes the right directions.
Are you fine with me pushing to this branch, or should I open PRs against your branch?

@noughtmare
Copy link
Contributor Author

I'm fine with pushing directly to my branch if that is possible. Do I need to give you special permissions?

@fendor
Copy link
Collaborator

fendor commented Nov 19, 2024

I don't know, I will just try to push at some point and ping you if I have any trouble :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Issues about memory consumption, responsiveness, etc. status: needs review This PR is ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants