Detect dead exports or package imports
Weeder 2.0 is being developed at https://github.com/ocharles/weeder on different foundations. This repo is for historical reference only.
Most projects accumulate code over time. Weeder detects unused Haskell exports, allowing dead code to be removed (pulling up the weeds). Weeder piggy-backs off files generated by
stack, so first obtain stack, then:
weederby running
stack install weeder --resolver=nightly.
stack.yamlfile. If you don't normally build with
stackthen run
stack initto generate one.
ghc-options: {"$locals": -ddump-to-file -ddump-hi}in your
stack.yaml.
weeder . --build, which builds your project with
stackand reports any weeds.
Weeder detects a bunch of weeds, including:
helperfrom module
Foo.Bar, but nothing else in your package uses
helper, and
Foo.Baris not an
exposed-module. Therefore, the export of
helperis a weed. Note that
helperitself may or may not be a weed - once it is no longer exported
-fwarn-unused-bindswill tell you if it is entirely redundant.
dependson another package but doesn't use anything from it - the dependency should usually be deleted. This functionality is quite like packunused, but implemented quite differently.
other-modulesfield that are either unused (and thus should be deleted), or are missing (and thus should be added). The
stacktool warns about the latter already.
.cabalfile - e.g. in both the library and the executable. Usually it's better to arrange for the executable to depend on the library, but sometimes that would unnecessarily pollute the interface. Useful to be aware of, and sometimes worth fixing, but not always.
.cabalfile. This situation can be because the file is unused, or the
stackcompilation was incomplete. I recommend compiling both benchmarks and tests to avoid this warning where possible - running
weeder . --buildwill use a suitable command line.
Beware of conditional compilation (e.g.
CPPand the Cabal
flagmechanism), as these may mean that something is currently a weed, but in different configurations it is not.
I recommend fixing the warnings relating to
other-modulesand files not being compiled first, as these may cause other warnings to disappear.
Weeder detects dead exports, which can be deleted. To get the most code deleted from removing an export, use:
-fwarn-unused-binds -fwarn-unused-imports, which finds unused definitions and unused imports in a module.
ctagsinformation, so can be used if you don't want to use
stack, can't compile your code, or want to detect unused code between projects.
If you want your package to be detected as "weed free", but it has some weeds you know about but don't consider important, you can add a
.weeder.yamlfile adjacent to the
stack.yamlwith a list of exclusions. To generate an initial list of exclusions run
weeder . --yaml > .weeder.yaml.
You may wish to generalise/simplify the
.weeder.yamlby removing anything above or below the interesting part. As an example of the
.weeder.yamlfile from
ghcid:
- message: Module reused between components - message: - name: Weeds exported - identifier: withWaiterPoll
This configuration declares that I am not interested in the message about modules being reused between components (that's the way
ghcidworks, and I am aware of it). It also says that I am not concerned about
withWaiterPollbeing a weed - it's a simplified method of file change detection I use for debugging, so even though it's dead now, I sometimes do switch to it.
Before running Weeder on your continuous integration (CI) server, you should first ensure there are no existing weeds. One way to achieve that is to ignore existing hints by running
weeder . --yaml > .weeder.yamland checking in the resulting
.weeder.yaml.
On the CI you should then run
weeder .(or
weeder . --buildto compile as well). To avoid the cost of compilation you may wish to fetch the latest Weeder binary release.
For the CI systems Travis, Appveyor and Azure Pipelines add the line:
curl -sSL https://raw.github.com/ndmitchell/weeder/master/misc/run.sh | sh -s .
The arguments after
-sare passed to
weeder, so modify the final
.if you want other arguments. This command works on Windows, Mac and Linux.
Weeder requires the textual
.hifile for each source file in the project. Stack generates that already, so it was easy to integrate in to. There's no reason that information couldn't be extracted by either passing flags to Cabal, or converting the
.hifiles afterwards. I welcome patches to do that integration.
Weeder strives to avoid incorrectly warning about something that is required, if you find such an instance please report it on the issue tracker. Unfortunately there are some cases where there are still false positives, as GHC doesn't put enough information in the
.hifiles:
Data.Coerce If you use
Data.Coerce.coercethe constructors for the data type must be in scope, but if they aren't used anywhere other than automatically by
coercethen Weeder will report unused imports. You can ignore such warnings by adding
- message: Unused importto your
.weeder.yamlfile.
Declaration QuasiQuotes If you use a declaration-level quasi-quote then weeder won't see the use of the quoting function, potentially leading to an unused import warning, and marking the quoting function as a weed. The only solution is to ignore the entries with a
.weeder.yamlfile.
Stack extra-deps Packages marked extra-deps in your
stack.yamlwill be weeded, due to a bug in
stack. The only solution is to ignore the packages with a
.weeder.yamlfile.
Linking to C functions If a library provides C functions, and these are used directly from another library/executable, the library providing these functions may be marked as a redundant
build-depends, see more details.