Squelched warning output when building multiple packages

[sw17ch]

Hi All,

Warning output is squelched when referring to external locations. Warning output is produced on the console when -Werror is present. The following pair of projects demonstrates the problem on the latest version of stack (1.1.2).

STACK_TEST.zip

This pair of projects was produced and tested with the following sequence of actions.

Check your stack version.

$ stack --version
Version 1.1.2 x86_64 hpack-0.14.0

Create two new projects.

stack new stacktest
stack new stackdep

Edit the stack.yaml file in stacktest to match the following.

resolver: lts-6.14

packages:
- '.'
- location: ../stackdep

extra-deps: []

flags: {}

extra-package-dbs: []

Edit src/Lib.hs in stacktest to match the following.

module Lib
    ( someFunc
    ) where

thisShouldGenerateAWarning = undefined

someFunc :: IO ()
someFunc = putStrLn "someFunc"

Edit stacktest.cabal to resemble the following. Of note is the ghc-options line.

$ cat stacktest/stacktest.cabal
name:                stacktest
version:             0.1.0.0
synopsis:            Initial project template from stack
description:         Please see README.md
homepage:            https://github.com/sw17ch/stacktest#readme
license:             BSD3
license-file:        LICENSE
author:              John Van Enk
maintainer:          sw17ch@gmail.com
copyright:           2016 John Van Enk
category:            Web
build-type:          Simple
-- extra-source-files:
cabal-version:       >=1.10

library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       base >= 4.7 && < 5
  default-language:    Haskell2010
  ghc-options:         -Wall

EXPECTED: two warnings in the build output of src/Lib.hs when building stacktest.

    /Users/johnvanenk/STACK_TEST/stacktest/src/Lib.hs:5:1: Warning:
        Defined but not used: ‘thisShouldGenerateAWarning’

    /Users/johnvanenk/STACK_TEST/stacktest/src/Lib.hs:5:1: Warning:
        Top-level binding with no type signature:
          thisShouldGenerateAWarning :: forall t. t

ACTUAL: no warning output is emitted.

$ stack build
stackdep-0.1.0.0: unregistering (local file changes: src/StackDep.hs stackdep.cabal)
stacktest-0.1.0.0: configure
stacktest-0.1.0.0: build
stackdep-0.1.0.0: configure
stacktest-0.1.0.0: copy/register
stackdep-0.1.0.0: build
stackdep-0.1.0.0: copy/register
Completed 2 action(s).

Further notes.

The warnings are still present in the log files, but no indications that warnings exist in the build are present on the console.

$ grep -Irn Warning .
./.stack-work/logs/stacktest-0.1.0.0.log:5:src/Lib.hs:5:1: Warning:
./.stack-work/logs/stacktest-0.1.0.0.log:6:    Defined but not used: ‘thisShouldGenerateAWarning’
./.stack-work/logs/stacktest-0.1.0.0.log:8:src/Lib.hs:5:1: Warning:
./.stack-work/logs/stacktest-0.1.0.0.log:10:      thisShouldGenerateAWarning :: forall t. t

Furthermore, turning on -Werror produces the warning output as expected, but is sometimes awkward when doing large refactors.

This behavior does not appear to exist when using extra-deps without a package in some other location as specified by a location directive.

[Blaisorblade]

Thanks for the report. In that scenario stack should silence warnings for the external dependencies, but this seems* to overreach.
But the internal logic seems another one: stack prints warnings to the console if there's a single package being built—or do I misunderstand? What happens if you first build dependencies and then your package?

Technically, my first guess is: is this code the culprit?

    console = wanted
           && all (\(ActionId ident _) -> ident == taskProvides) (Set.toList acRemaining)
           && eeTotalWanted == 1

[borsboom]

This may be a duplicate of #426 and #298.

[dysinger]

I was able to reproduce this also - even without the "location" qualifier on one of the projects.

test:

% cd /tmp
% mkdir testymctestcase
% cd testymctestcase
% stack new thinga
% stack new thingb
% cat >stack.yaml <<\EOF
resolver: lts-6.14
packages:
  - "thinga"
  - "thingb"
ghc-options:
  '*' : '-Wall'
EOF
% echo 'main = undefined' | tee thinga/app/Main.hs
% stack build
... no warnings ...
% 

[borsboom]

The #426 (--ghc-output) solution is not all that discoverable; a user would need to know to use it in order to see warnings. Potentially Stack could detect warnings in GHC's output when it's squelched due to parallel builds (there's already some logic for detecting warnings in order to munge filenames into absolute paths) and if it sees any dump that build's output to the terminal. We'd have to make sure this doesn't end up consuming a lot of memory or otherwise hurt performance though.

[ppelleti]

#426 is a bit different, in that it wants a realtime indication of progress. It seems to be stuck in concerns about interleaved output.

The problem with warnings (this bug) could be solved by waiting for the build to finish, and then dumping the log files to stderr for all local packages that were built.

[snoyberg]

I opened up #2594 with a dump-logs config option/flag. I'd consider it a fix for #426, and presumably this issue too.

[snoyberg]

Also of note: I've opened up #2596, which ensures that local extra-dep packages are in fact treated as dependencies for both purposes of stack test and for deciding whether or not to send build output to the console.

[borsboom]

@snoyberg: perhaps what you did in #2596 could be adapted to fully solve this issue by having default behaviour that detects any warnings in the logfile and dump it if any are found. We already have some code to detect warnings in GHC output in order to make displayed file paths absolute.

At least, I think that would be desirable default behaviour. Any other opinions here?

[snoyberg]

I think #2596 should be treated as an orthogonal bug fix which restores correct behavior for dependency vs non-dependency packages. I'd actually consider this closer to the behavior change being done in #2594, and it sounds like we could have three settings of dumping logs:

• Dump all logs for targets, all the time
• Never dump logs for targets
• Dump logs for targets when the logs have warnings in them

It would certainly be easy to extend the dump-logs code I already wrote to account for this.

[borsboom]

[reopened since warning output is still "squelched" by default when building multiple packages]