search

ndmitchell / weeder

Detect dead exports or package imports
BSD 3-Clause "New" or "Revised" License
124 stars 8 forks source link

Feature request: option to detect library exports not used in executables/tests #23

Closed bucklereed closed 7 years ago

bucklereed commented 7 years ago

weeder must assume that a library component can be depended upon by external packages and that all of its exports must be 'live'. However, a common pattern is for conceptually executables-only packages to have a library component, so that code can be shared across multiple executables and the test suite without recompilation; in this design, any exports from the library that aren't used by other components are 'weeds', and it would be handy for weeder to report them. Since weeder can't automatically distinguish between this case and the also-common pattern of a suitable-for-external-consumption library + executables all in one package, it would need to be an explicit toggle (e.g., probably a command-line switch).

ndmitchell commented 7 years ago

I'm afraid this isn't possible. GHC tracks precisely what pieces are used within a library, but as soon as you go into a different executable/library it just says that you depend on "something" in the library. As a result, all I can see is that the executable depends on some of the library, not which parts, so don't really have much analysis I can do.

ocharles commented 7 years ago

You have dump-minimal-imports, is there a way we could use that? Or perhaps weeder could accept an extra input of symbols that are used, and could ship a tool that could re-generate this automatically.

ndmitchell commented 7 years ago

Minimal imports might be feasible, only question would be how to get this information out of stack? It currently passes the dump-hi flag because it needs it. If there was an easy way to generate it always I'd certainly think about what we could do with it.

bucklereed commented 7 years ago

Unless I'm misunderstanding, wouldn't passing --ghc-options=-ddump-minimal-imports to stack be sufficient? (And probably --force-dirty, on reflection.)

Also, this feature would be even handier with Cabal 2's internal libraries, which don't require any guessing about internal/external-ness.

ndmitchell commented 7 years ago

Yep, you could do it be rejigging stack - but that itself is quite a lot of pain. There's a lot to be said for just reusing a previous stack build.

I am sceptical that the internal libraries are a good idea at all - my opinion is that they're a nasty hack to get around the fact that Cabal is file based and not module based...