-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Fix build and tests with GHC-9.4.3 and 9.2.5 #3364
Conversation
haskell-language-server.cabal
Outdated
if impl(ghc >= 9.4) | ||
build-depends: ghc-exactprint >= 1.6.1 |
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.
why is this needed?
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.
Ah, a good question. Without this seemingly unnecessary constraint, Cabal somehow manages to pull ghc-exactprint-1.6.0
- presumably because there's a dependency of dependency that's asking for it. And CI tests kept failing.
With this addition, all the relevant tests passed (that is - at least, until I started applying changes to address suggestions ;).
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.
I really think this needs to go in the right place. It shouldn't be that hard to figure out. At the very least it needs a clear comment explaining this.
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.
I really think this needs to go in the right place
I attempted to find the right place - starting with attempts to put it in plugins/hls-refactor-plugin
and ghcide
. Failed miserably in both cases - tests kept failing. Please feel free to pitch a hand and locate that right place - I don't know nearly enough to dig deeper. I tried to search/grep for exactprint
, and did not come up with anything helpful (besides the above, which did not help either).
If you do know that right place, please share. Or, perhaps, create a new PR - I'm already up to my ears in the bog of CI that I don't understand.
The current workaround was prompted by observation that
$ ghcup compile hls -g master --ghc 9.4.3 -- --index-state=@<current_date> --constraint="ghc-exactprint >= 1.6.1"
works.
How would you want me to explain it? Just copy-paste this post into the .cabal
file?
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 is not necessary, afaict, this worked for me out of the box:
> cabal update
> cabal build -w ghc-9.4.3 exe:haskell-language-server
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.
Interesting - perhaps, index-state
changed since...? Should I update index-state
in this PR too?
Also, have you tried just cabal build -w ghc-9.4.3
(to build whatever's there)?
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.
Since you updated the index-state in cabal.project, you locally need to make sure your global index-state is newer than the one in cabal.project (which you added). So just running cabal update
in the project or outside of it should do the trick.
Yeah, works just the same. It'd be weird if cabal didn't choose the most recent version of 'ghc-exactprint'.
Co-authored-by: Pepe Iborra <pepeiborra@me.com>
build-depends: fourmolu ^>= 0.8.2 | ||
if impl(ghc >= 9.4) | ||
build-depends: fourmolu ^>= 0.9 | ||
|
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.
I'm a bit confused by exactly why this is done this way (same as #3364 (comment), basically). But if it passes CI I'm fine with it.
I'll revisit all these bounds next time I come along to bump the version.
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.
I'm a bit confused by exactly why this is done this way
Mainly, because I don't know any better. It seemed to be a crude but correct way to get tests pass.
I'll be happy if somebody with more knowledge fixes this the right way.
I don't know what to do with this test failure (GHC-9.4.3, ubuntu-latest):
|
The testcases you mention are expected failures and require no action.
might be a genuine bug. |
Very likely so. But I don't see how this PR could be related, or how to fix it. Or even whether the fix should belong to this PR. |
Well, if the PR that adds support for GHC 9.4.3, and the test-suite for GHC 9.4.3 breaks, then it is related because GHC changed something, somehow and now some assumption we previously had does not hold anymore. In other words, HLS is not compatible with GHC 9.4.3 out of the box. A fix may very well belong into this PR, and the fix is likely to be rather minor, but potentially very hard to track down. |
I call it "limited support". ;-)
My only/main reason to ignore this test is that I don't have the slightest clue how to go about fixing, let alone actually fixing it. The change to make HLS build and pass the majority of the tests seems fairly small and simple. The choice appears to be between providing some support for GHC-9.4.3 now, or waiting for an unknown length of time until somebody with enough knowledge figures out what's wrong and makes all the tests pass. Also, what should we do with GHC-9.2.5? Stackage released LTS for it, but there's no official HLS support yet. |
Is there any way to make tests continue with other GHC versions rather than cancel, if one fails? |
No, this is by design to spare some CI resources. |
I understand that. But here it looks like we need to know which GHC versions do and which do not fail the tests, with the given changes. |
Remove forcing `ghc-exactprint >= 1.6.1`, checking if @fendor 's suggestion is correct
@mouse07410 you could mark the test as an expected failure in ghc 9.4.5. This will allow CI to continue past the error. |
Please excuse my ignorance. How to do that? |
Use the |
I see, thanks. Frankly, I think it is beyond my competency to start messing with the code. Perhaps, one of the maintainers would care to tweak these? |
The currently broken master CI makes us hard to work on. (We are currently trying to land some changes for GHC 9.4 such as #3317 but could not make progress related to CI failures) |
@wavewave what is broken in master CI and what parts of this PR would help unblock you? |
C'mon, just look at the most recent You can see that most of the checks in #3317 are failing. We need this PR to fix those checks. I believe this PR will be necessary but perhaps not sufficient to fix those checks. |
Can you be more explicit? I don't see any checks failing other than the Nix ones.
I see that there is a build error in a dependency:
Can you clarify how this PR fixes that? |
@pepeiborra |
Superseded by #3396 |
It is certainly a problem that our CI checks are flaky, yeah. But I don't believe that master or anything else is actually broken. |
Fixes build with GHC-9.4.3.
Includes workaround for apparently-broken
implicit-hie
0.1.3.