stack typecheck

[ezyang]

Stack should have a mode similar to build which only typechecks files. This can be done (with recomp avoidance) by passing -fwrite-interface -fno-code to GHC. I can't use --ghc-options to do this today because Stack passes those flags to build the Setup script, which obviously needs to be built for real (it is a bit odd that Stack always builds a setup script).

[snoyberg]

I don't believe this is accurate. Instead, it appears that Cabal, when configure, chokes on these arguments. Consider these three different configure attempts with the options specified:

vagrant@vagrant-ubuntu-trusty-64:~/Desktop/foobar$ stack build --ghc-options "-fwrite-interface -fno-code"
foobar-0.1.0.0: configure
Configuring foobar-0.1.0.0...
setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2:
/tmp/1957747793424238335.o: does not exist

--  While building package foobar-0.1.0.0 using:
      /home/vagrant/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ configure --user --package-db=clear --package-db=global --package-db=/home/vagrant/.stack/snapshots/x86_64-linux/lts-3.4/7.10.2/pkgdb/ --package-db=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/pkgdb/ --libdir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/lib --bindir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/bin --datadir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/share --libexecdir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/libexec --sysconfdir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/etc --docdir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/doc/foobar-0.1.0.0 --htmldir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/doc/foobar-0.1.0.0 --haddockdir=/home/vagrant/Desktop/foobar/.stack-work/install/x86_64-linux/lts-3.4/7.10.2/doc/foobar-0.1.0.0 --dependency=base=base-4.8.1.0-4f7206fd964c629946bb89db72c80011 --ghc-options -fwrite-interface -fno-code --enable-tests --enable-benchmarks
    Process exited with code: ExitFailure 1
vagrant@vagrant-ubuntu-trusty-64:~/Desktop/foobar$ cabal configure --ghc-options="-fwrite-interface -fno-code"
Resolving dependencies...
Configuring foobar-0.1.0.0...
cabal: /tmp/1957747793424238335.o: does not exist
vagrant@vagrant-ubuntu-trusty-64:~/Desktop/foobar$ runghc Setup.hs configure --ghc-options="-fwrite-interface -fno-code"
Configuring foobar-0.1.0.0...
Setup.hs: /tmp/1957747793424238335.o: does not exist

In other words: Cabal is trying use those options during configuration to generate an object file, and -fno-code is preventing that from working.

[ezyang]

OK, that diagnosis sounds more right. In any case, since cabal build supports --ghc-options being passed to it post-configure, I can work around it with Cabal; Stack has no such mechanism.

[nominolo]

As more of a side note, -fno-code will not run the desugarer. This in turn means that it will miss warnings that are detected in that phase, in particular pattern exhaustiveness checking. I don't know if there are also errors caught in that phase.

So, the question is whether users would expect a "typecheck" command to include those kinds of errors. They would show up when running stack build or stack test, of course.

[ezyang]

Here's the GHC bug for this infelicity: https://ghc.haskell.org/trac/ghc/ticket/10600

Personally I think it's OK for those errors to be missing. It's just a gotcha due to an underlying bug.

[ghorn]

This would be great for reducing the debugging time. In a large project with many dependencies, I have to wait minutes to recompile everything if I edit a core module. I don't think "stack ghci" quite fills that gap because it misses the executables.

[mgsloan]

True! If only we could load multiple main files and even packages into ghci - https://ghc.haskell.org/trac/ghc/ticket/10827

I'd certainly merge a PR for it

[MaxGabriel]

Just saw this issue referenced on Reddit and wanted to comment that the underlying GHC issue has been fixed: https://ghc.haskell.org/trac/ghc/ticket/10600

Unclear to me if it made it into 8.2 or it's just ready for 8.4

[fosskers]

This would be very nice if incorporated into the behaviour of stack build --file-watch --fast

[mgsloan]

I think it'd make sense to have this be a flag rather than a command. Here's why:

1. It's more than just typecheck because it's also parsing etc, so it's more similar to just check. However, that brings to mind cabal check but that's quite different. So I don't think adding a stack check command would be good.

2. We already have quite a few top level commands, best to only add things carefully.

3. It would be consistent with flags like --only-configure to have a flag like --only-check.

So, I propose that it be stack build --only-check, if someone implements this.

[nh2]

I'm using this for now for fast typechecking: stack ghci "--ghci-options=-e 1".

That just loads everything into ghci and evaluates "1", or fails if typechecking fails.

Especially useful in combination with git:

GIT_SEQUENCE_EDITOR=touch git rebase -i --exec 'stack ghci "--ghci-options=-e 1"' origin/master

This typechecks each individual commit I have locally on top of master.

(See here for more info on rebase, and here for setting GIT_SEQUENCE_EDITOR=touch so that it works fully non-interactively.)

[buggymcbugfix]

Any updates on this issue? Is this something a beginner could work on?

[dbaynard]

No updates, and yes, suitable for a beginner. I believe ghcid does something very similar to this — it may be worth investigating that with @ndmitchell.

One complication may concern template-haskell; I'm not sure how to handle that when using -fwrite-interface -fno-code.

[ndmitchell]

ghcid doesn't seek to write interfaces, so is a good bit simpler.

[dbaynard]

Oh, ok — thanks.

I've also just noticed that backpack allows typechecking modules that have only signatures (i.e. no code) and so this may be more complicated than it would appear. Note that stack doesn't yet support backpack, but backpack ought to be considered when implementing this change.

[dbaynard]

#4545 (in progress) changes stack's behaviour regarding '.hi' files