-
Notifications
You must be signed in to change notification settings - Fork 52
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
use weeder #2044
use weeder #2044
Conversation
41a00e9
to
e554ab6
Compare
I tried it too, but gave up after the false positives. I did not notice that running HLS in VSCode has an impact, maybe I should give it a second try. 🤔 |
24340a7
to
57f9e49
Compare
6767735
to
c4dd1f0
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.
Great work, thanks!
My concern with editing haskell-ci.yml
manually like this is that these changes might be lost next time we automatically regenerate it. At the very least, we should add some clear comments to the top of the file explaining which parts need to be left alone (we already have such a comment, about the custom on.push
and on.pull-request
conditions).
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.
Amazing, thanks @kostmo! 👍
23644c4
to
9902ee7
Compare
Closes #2043
Local usage notes
I suspect that HLS in VS Code spontaneously pollutes the
.hie
directory, because after a few successful invocations,weeder
started complaining with:Fixing false positives
Previously, for each
library
andexecutable
, the HIE directory was always the same:However, most of the executables have at least one module path that is the same relative to their
hs-source-dirs
base: namely,Main.hs
. This resulted in all but one of theMain.hie
files being overwritten in the end.To avoid this, I have specified a different
-hiedir
for eachlibrary
/executable
/test
that parallels itshs-source-dirs
base. This way, so long ashs-source-dirs
are unique across these targets, all of the*.hs
files across the entire project will have unique*.hie
paths.Whitelisting exceptions
There are some known limitations with
weeder
regarding support for Template Haskell and type families. Exceptions are specified in theroots
list inweeder.toml
.After removing a handful of dead functions myself, there are approx. 30 "true positive" weeds that I have listed explicitly in
weeder.toml
. Maintenance of this list of exceptions should eventually be easier with ocharles/weeder#146.Integration with CI
I found a ready-made GitHub Action for weeder: https://github.com/freckle/weeder-action
I hacked support directly into the generated
.github/workflows/haskell-ci.yml
file.Ideally, the generator would have an option for a
weeder
step. Indeed, there is an open issue for supportingweeder
inhaskell-ci
: haskell-CI/haskell-ci#132A separate but related functionality that would be nice in
haskell-ci
is to specify one of the GHC versions in the matrix to do additional validations/builds that would be redundant if performed on the other matrix entries. I supposeweeder
is inexpensive enough to redo four times, but theweeder
binary is not available for download for all GHC versions (e.g. ghc9.8.2
). Something likehaddock
we probably only need to build once.I have hacked this in to the generated file for
weeder
with a simpleif
condition.