stack setup claims to be using a sandboxed GHC when using a system-wide one

[Blaisorblade]

General summary/comments (optional)

stack setup can claim to be using a sandboxed GHC when in fact using a system one. I think it's a regression and this used to work (at a time when system GHC was the default).

Steps to reproduce

1. Install a system-wide GHC (e.g. 8.0.2.)
2. Pick a compatible resolver (e.g. nightly-2017-01-31)
3. Run stack setup --system-ghc --resolver $resolver, e.g.

$ stack setup --system-ghc --resolver nightly-2017-01-31
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

My config.yaml:

install-ghc: false
ghc-options:
  "*": -j3

(I also had system-ghc and newer-minor enabled there, but the bug appears with them disabled, too).

Expected

I expected stack to tell me it's using a system-installed GHC.

Actual

Stack claims it's using a sandboxed GHC.

Verbose output

$ stack setup --system-ghc --resolver nightly-2017-01-31 --verbose
Version 1.3.2 x86_64 hpack-0.15.0
2017-01-31 22:04:25.145277: [debug] Checking for project config at: /Users/pgiarrusso/AeroFS/Repos/stack-bluevelvet/stack.yaml
@(Stack/Config.hs:863:9)
2017-01-31 22:04:25.146516: [debug] Loading project config file stack.yaml
@(Stack/Config.hs:881:13)
2017-01-31 22:04:25.150348: [debug] Trying to decode /Users/pgiarrusso/.stack/build-plan-cache/x86_64-osx/nightly-2017-01-31.cache
@(Data/Store/VersionTagged.hs:68:5)
2017-01-31 22:04:25.170540: [debug] Success decoding /Users/pgiarrusso/.stack/build-plan-cache/x86_64-osx/nightly-2017-01-31.cache
@(Data/Store/VersionTagged.hs:72:13)
2017-01-31 22:04:25.183141: [debug] Getting system compiler version
@(Stack/Setup.hs:370:17)
2017-01-31 22:04:25.183866: [debug] Run process: /usr/local/bin/ghc --info
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:25.363289: [debug] Process finished in 179ms: /usr/local/bin/ghc --info
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:25.367814: [debug] Performing a sanity check on: /usr/local/bin/ghc
@(Stack/Setup.hs:1495:5)
2017-01-31 22:04:25.367968: [debug] Run process: /usr/local/bin/ghc /private/var/folders/_7/hlxv4yv95x95vgnn416b4q4m0000gp/T/stack-sanity-check76911/Main.hs -no-user-package-db
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:26.143417: [debug] Process finished in 775ms: /usr/local/bin/ghc /private/var/folders/_7/hlxv4yv95x95vgnn416b4q4m0000gp/T/stack-sanity-check76911/Main.hs -no-user-package-db
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:26.144330: [info] stack will use a sandboxed GHC it installed
@(Stack/SetupCmd.hs:109:19)
2017-01-31 22:04:26.144483: [info] For more information on paths, see 'stack path' and 'stack exec env'
@(Stack/SetupCmd.hs:110:5)
2017-01-31 22:04:26.144564: [info] To use this GHC and packages outside of a project, consider using:
@(Stack/SetupCmd.hs:111:5)
2017-01-31 22:04:26.144688: [info] stack ghc, stack ghci, stack runghc, or stack exec
@(Stack/SetupCmd.hs:112:5)

Stack version

$ stack --version
Version 1.3.2 x86_64 hpack-0.15.0

Method of installation

• Homebrew package (which, apparently, is a supported approach, though the script looks scary).

[mgsloan]

Good catch! I've pushed a fix