When I prototype Haskell programs, I always get hundreds of warnings like this (not joking):
/Users/bob/SourceCode/course/is/expriment/LiftedSpine2.hs:70:15:
Warning: Defined but not used: `ta'
/Users/bob/SourceCode/course/is/expriment/LiftedSpine2.hs:72:15:
Warning: Defined but not used: `ta'
/Users/bob/SourceCode/course/is/expriment/LiftedSpine2.hs:77:26:
Warning: Defined but not used: `v'
Is there anyway to remove these warnings temporarily?
I tried putting this in my .hs file:
{-# OPTIONS_GHC -fno-warn-unused-binds -fno-warn-name-shadowing
-fwarn-monomorphism-restriction -fwarn-hi-shadowing
#-}
Unfortunately, it does not work, and although I also tried to :set -fno-warn-unused-binds, it still does not work.
Many thanks!
Another possibility, depending on your situation: I believe you can prefix identifiers with an underscore to suppress this warning. So:
_x = 42
will not generate the warning if _x is not used.
GHC has two warnings flags which can trigger Warning: Defined but not used.
You need some combination of the command line flags -fno-warn-unused-binds and -fno-warn-unused-matches.
I usually use -w to suppress all warnings when I want get rid of some warning temporarily.
I use a workaround for this:
I compile without warnings, but then I use HLint tool to display warnings for me. HLint has facilities to turn warnings separately.
Related
When parsing source codes with c preprocessor enabled, the parser doesn't like undefined macros like MIN_VERSION_packagename(a,b,c). How can I get cabal/ghc tell cpp the package info and add the macro definitons?
You can use the very idiomatic (/s) options:
ghc -optP-include -optPdist/build/autogen/cabal_macros.h
I happen to have just been writing a pull request to doctest about this, you may be interested in referencing it:
https://github.com/sol/doctest/pull/109/files#diff-438bc19bd41887f8cacb796eaa990b0aR81
I am writing a module that relies on optimization. I want to test this module in ghci. But starting ghc in --interactive mode automatically disables optimization; if I compile the module with -O and then try to load it in an interactive session, ghc insists on loading it in interpreted mode.
For a simple test case to distinguish optimized and unoptimized modules, isOptimized below evaluates to True with optimization on, but False with optimization off:
isOptimized :: Bool
isOptimized = g
g :: Bool
g = False
{-# NOINLINE g #-}
{-# RULES "g/True" g = True #-}
Either use ghci -fobject-code -O Test.hs or cabal repl --ghc-options="-fobject-code -O". In more detail:
ghci must be invoked with the -fobject-code flag.
Optimization flag(s) must be given after -fobject-code on the command line, or in an OPTIONS_GHC pragma at the top of the module. Trying ghc --interactive -O -fobject-code produces a warning that "-O conflicts with --interactive; -O ignored." This is perhaps a bug.
If you're working on a cabalized project and using cabal repl, you need to pass the flags either on the command line (i.e. cabal repl --ghc-options="-fobject-code -O") or in a pragma. Cabal (currently) discards optimization flags set in the .cabal file with ghc-options when invoking ghci; in fact, it explicitly sets -O0 instead. This is perhaps a bug.
Note in any case that you sometimes need to force recompilation manually when switching between optimized and unoptimized mode. Build artifacts are, for some reason, not invalidated when the optimization flags change so long as -fobject-code remains on. If, starting from a clean slate, you have -fobject-code set in your .cabal file, run cabal repl which compiles the module, and then remember you need to set -O on the command line and run cabal repl --ghc-options=-O, ghc will happily load the previously-compiled, unoptimized module. This is also perhaps a bug.
The most reliable scenario for testing a single module seems to be to put {-# OPTIONS_GHC -fobject-code -O #-} at the top of the module. You will get optimized code no matter how you invoke ghci. I haven't investigated what happens in multi-module situations where some but not all modules have the pragma.
Incidentally, note that only code in the module is optimized. Even with optimization on, evaluating g in the repl will always produce False, because the repl input is not subject to rewrite rules.
I'm using the MultiWayIf language extension. While I love HLint (I'm using version v1.8.61), unfortunately it appears that HLint is not aware of this extension, and it reports multi-way ifs as parse errors:
Warning: Parse error: |
The HLint Manual (http://community.haskell.org/~ndm/darcs/hlint/hlint.htm) describes how you can use pragmas to indicate suggestions to ignore; however, this doesn't seem to work for warnings due to parse errors.
Is there any way to tell HLint to ignore the parse error warnings?
Thank you!
You can run:
hlint "--ignore=Parse error" MyFile.hs
There is a test that this invocation works in the HLint test suite.
Note that as soon as there is a parse error you won't get any other hints from the file, since HLint can't operate on a file until it is parsed.
However, if you upgrade to haskell-src-exts-1.15 or higher then reinstall HLint it should parse multi-way-if fine. If not, please report a bug.
I'm following the Yesod book, which states:
But by using the -ddump-splices GHC option, we can get an immediate
look at the generated code. A much cleaned up version of it is:
How would I do this? I've tried compiling my file with ghc -XTemplateHaskell -ddump-splices Page.hs, which leaves the directory as follows:
Page Page.hi Page.hs Page.hs~ Page.o
None of these files, however, contain the intermediate code generated by Template Haskell.
http://www.yesodweb.com/book/basics
Meanwhile the behaviour changed and the -ddump-to-file flag in addition to the -ddump-splices flag causes the splices to be written to a file, see Section 9.26 of the current (GHC 8.2.1) documentation for more details.
On older versions of GHC (I didn't check in which version exactly the behaviour changed), -ddump-splices worked differently:
The -ddump-splices option causes GHC to dump the splices to stderr. Unfortunately, the -ddump-to-file flag doesn't affect splices (I don't know whether that has deeper reasons or is just an oversight), so you need to capture the stderr output to save the splices for later investigation,
ghc -XTemplateHaskell -ddump-splices Page.hs 2> Page.dump-splices
on sufficiently bash-like shells.
In large projects doing this for all modules is problematic.
Fortunately, you can dump per module.
This also works in ghci.
You can add this line to the top of your module
{-# OPTIONS_GHC -ddump-splices #-}
It dumps it to stderr.
{-# OPTIONS_GHC -ddump-to-file #-}
is also usefull which puts the dump in a file next to the module with the prefix .dump-simpl.
See reference: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debugging.html#ghc-flag--ddump-to-file
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debugging.html#ghc-flag--ddump-splices
You can add these as separate lines (for easy copy pasting)
I have a module which binds to a C function using the FFI. How can I make this module use doctest?
The error I get when running doctest Foo.hs is something like this:
ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
bar
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs#haskell.org
### Failure in Foo.hs:41: expression `foo'
expected: [42]
but got:
<interactive>:24:1: Not in scope: `bar'
Examples: 2 Tried: 2 Errors: 0 Failures: 1
Doctest accepts arbitrary GHC flags. If you want to run Doctest with FFI code you need to pass the exact same flags that you would need to run a GHCi session with that code. Have e.g. a look at the Doctest driver of unix-time.