Stack does not apply GHC options in package.yaml

[ad-si]

General summary/comments

I have defined several GHC -W options in my package.yaml.
When I run ghcid or stack ghci they are applied and I get the corresponding warnings.
However, when I run stack build no warnings appear.

Maybe related to #4526 or #4548

Steps to reproduce

1. stack new test
2. Add - -Wall to ghc-options in package.yaml
3. Add let unused = 123 to src/Lib.hs
4. Run stack ghci and obsoerve the warning
5. Run stack build and observe no warning

Expected

A -Wunused-local-binds warning to appear

Actual

No warnings whatsoever

The .cabal file contains has the correct ghc-options, so it's apparently not a problem of transforming the hpack config into the cabal config.

Stack version

$ stack --version
1.9.3 x86_64
Compiled with:
- hpack-0.31.1
…

Method of installation

brew install stack

[qrilka]

@ad-si what section of package.yaml did you add -Wall to? In the default one there's ghc-options for test-exe and tests, if you want to have a warning for a library source code you should add it into library section of package.yaml/Cabal file

[ad-si]

library:
  source-dirs: source

executables:
  tasklite:
    main: Main.hs
    source-dirs: app
    ghc-options:
      - -Wall
      - -Wcompat
      - -Wincomplete-record-updates
      - -Wincomplete-uni-patterns
      - -Wredundant-constraints
      - -fno-warn-orphans
    dependencies:
      - tasklite

That's what it looks like at the moment. I can't see anything about a ghc-options field for the library section. How do I need to change it?

[qrilka]

In the code that you show above ghc-options is applied only for the tasklite executable, you could add top level ghc-options: -Wall (and hpack will add it into all Cabal stanzas) or you could be more specific and add it into library like the following:

library:
  source-dirs: source
  ghc-options: -Wall

[ad-si]

Ok cool, thanks for the tip. Unfortunately that doesn't fix my problem. Still no warnings. 😔

[qrilka]

@ad-si showing the logs could help a lot. My suspicion is that you have your library already built so without a recompilation you won't get any warnings for sure. Just use stack clean before running stack build and you should be able to see your warning.

[ad-si]

Oh, wow, stack clean && stack build does indeed work.
But what the heck? That's really not what I would expect.

So this means it shows warnings only on the first compilation.
In this case I'd like to change this issue to "Show GHC warnings on every build",
just because one missed the warning it doesn't mean it's not relevant anymore, right?

I guesss I missed it because I was using `stack build --file-watch'. E.g. it built a file why I wasn't looking, then I made a change on another file and only then looked to the output. At this time, however, the warnings from the first file were already gone, never to be shown again.

Why isn't this a problem for ghcid or ghci?

[qrilka]

I suppose your "Show GHC warnings on every build" isn't quite correct here because consecutive builds by default recompile only changed files, if you want to trigger complete package recompilation you could either use stack clean or stack build --force-dirty --ghc-options=-fforce-recomp. See e.g. it mentioned in Stack docs

[ad-si]

"recompile only changed files" and "Show GHC warnings on every build" isn't a contradiction.
ghcid basically does it.
I think stack build should behave more like ghcid on consecutive runs.

[qrilka]

Stack could only show warnings from GHC and you won't get anything from it if compiler doesn't get invoked on a file which was already compiled. And as far as I understand GHCi loads all of the modules and ghcid works through GHCi so it is a contradiction between 2 different methods - loading modules in interpreter mode and module recompilation with GHC.
E.g. using the same Lib.hs:

qrilka@qdesktop ~/ws/h/stack-tmp/test $ ghc src/Lib.hs 
[1 of 1] Compiling Lib              ( src/Lib.hs, src/Lib.o )
qrilka@qdesktop ~/ws/h/stack-tmp/test $ ghc src/Lib.hs -Wall
qrilka@qdesktop ~/ws/h/stack-tmp/test $ rm src/Lib.o
qrilka@qdesktop ~/ws/h/stack-tmp/test $ ghc src/Lib.hs -Wall
[1 of 1] Compiling Lib              ( src/Lib.hs, src/Lib.o )

src/Lib.hs:10:1: warning: [-Wunused-top-binds]
    Defined but not used: ‘unused’
   |
10 | unused = 123
   | ^^^^^^

src/Lib.hs:10:1: warning: [-Wmissing-signatures]
    Top-level binding with no type signature: unused :: Integer
   |
10 | unused = 123
   | ^^^^^^

src/Lib.hs:10:10: warning: [-Wtype-defaults]
    • Defaulting the following constraint to type ‘Integer’
        Num p0 arising from the literal ‘123’
    • In the expression: 123
      In an equation for ‘unused’: unused = 123
   |
10 | unused = 123
   |          ^^^

[ad-si]

Well, I'm coming here solely from the user standpoint and when I run stack build I'm expecting it to build it and show me any warnings and errors in the process of doing so. Which stack is obviously not doing. That it reuses compiled modules under the hood is a nice feature, but it shouldn't influence the premise that it shows any warnings and errors.

One workaround I just found is to set -Werror, and disable irrelevant warnings on a per file basis (e.g. {-# OPTIONS_GHC -fno-warn-incomplete-record-updates #-}). Than I can't miss any warnings.
But this shouldn't be necessary 😕.

[qrilka]

You could as well use stack build --pedantic to fail on any (not suppressed) warning.
Overall this is not a detail of Stack itself you could open a ticket on GHC Trac if you want to discuss its behavior. As for this issue I'd propose to close it.

[ad-si]

So you're saying stack is only using ghc build and therefore it's a "bug" of ghc to not show any warnings?
If that's the case this issue can indeed be closed.

[qrilka]

It's a GHC behavior, see e.g. some details in https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/separate_compilation.html?highlight=fforce-recomp#ghc-flag--fforce-recomp and I don't think that it's a bug

[sharno]

I had the same issue and had to search through the issues to find this. I think this needs some clarification in the docs?

Also, it wasn't clear enough for me to put the ghc-options in the package.yaml. As the docs mention all the project specific options should be put in stack.yaml and then go on about the non-project specific options. I know the package.yaml file gets generated with ghc-options but I didn't know why the format in the docs is a map instead of an array options.

Putting ghc-options in stack.yaml doesn't have any effect.

[dbaynard]

@sharno The package.yaml and stack.yaml files are processed by different programs (even though stack bundles the program, hpack, which processes the former). I suspect that you're right, and the docs could be clarified. Would you like to contribute some suggestions?