flycheck/flycheck-haskell

Improved Haskell support for Flycheck

https://www.flycheck.org

Modern on-the-fly syntax checking extension for GNU Emacs. Try it!

Getting Started

Flycheck is available for installation with package.el on NonGNU ELPA, MELPA Stable and MELPA.

You can install Flycheck with the following command:

M-x package-install [RET] flycheck [RET]

Finally add this to your Emacs config:

(global-flycheck-mode +1)

Alternatively, if you're into use-package you can do the following:

(use-package flycheck
  :ensure t
  :config
  (add-hook 'after-init-hook #'global-flycheck-mode))

Now you can start using any of the bundled checkers or install additional checkers.

For a more gentle introduction read the Installation instructions and go through Quickstart guide.

Getting Help

Please ask questions about Flycheck on Stack Exchange or in our Gitter chat, and report bugs to our issue tracker.

Contributing

We welcome all kinds of contributions, whether you write patches, open pull requests, write documentation, help others with Flycheck issues, or just tell other people about your experiences with Flycheck. Please take a look at our Contributor’s Guide for help and guidance about contributing to Flycheck.

Sponsoring

You can support financially the development of Flycheck and related packages via:

• Open Collective
• GitHub Sponsors
• Patreon
• PayPal

Open Collective Backers

Open Collective Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]

Code of Conduct

We strive to create a safe, friendly and welcoming environment in the Flycheck community and have a Code of Conduct that defines acceptable and welcome behaviour as well as sanctions for violations. All contributors and all participants are expected to follow it, on Github, Gitter, Emacs.SX or any other place that’s part of Flycheck’s broader community.

License

Flycheck is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Flycheck is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

flycheck-haskell's Issues

hdevtools could not find module under the same directory

Not sure if this is a bug or I've done something wrong, but please help me troubleshoot this problem.

What I did is:

• create a new directory (e.g. /tmp/mod)
• create the following two files:

Mod.hs:

module Mod where

a = 1

Main.hs:

import Mod

main = print a

When editing Main.hs, an error is found on line 1 col 8 saying "Could not find module Mod"

I used C-c ! l to bring up the error list and found that error message comes from haskell-hdevtools

Related info

• flycheck-haskell 20141003.308
• hdevtools 0.1.0.6
• flycheck-haskell-hdevtools-executable customized

Switching GHC versions

If there are more than one Haskell installations present (e.g. I have 7.8.4, 7.10.3 and 8.0.1), is there a compact way of pointing flycheck-haskell at the desired one?

I'm encountering this "suspicious state from syntax checker haskell-stack-ghc" warning, since the checker is stuck at using 7.10, whereas I need to try something with 7.8 .

It's a single .hs file, there is no cabal or stack.yaml file, so the default "Try running stack setup to locally install the correct ghc" is misleading.

Thank you

flycheck-haskell fails to initialize when you have a cabal.config without 'with-compiler'

I have projects with cabal.config files, that only specify constraints. In the latest version of flycheck-haskell, it fails to initialize while looking for with-compiler.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  substring-no-properties(nil)
  flycheck-haskell-get-config-value(with-compiler)
  mapcar(flycheck-haskell-get-config-value (with-compiler))
  flycheck-haskell-parse-config-file((with-compiler) "/Users/nkpart/p/vlc/dredd/dredd/cabal.config")
  flycheck-haskell-get-cabal-config()
  flycheck-haskell-configure()
  run-hooks(flycheck-mode-hook flycheck-mode-on-hook)
  flycheck-mode()
  run-hooks(change-major-mode-after-body-hook prog-mode-hook haskell-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook prog-mode-hook haskell-mode-hook))
  run-mode-hooks(haskell-mode-hook)
  haskell-mode()
  set-auto-mode-0(haskell-mode nil)
  set-auto-mode()
  normal-mode()
  call-interactively(normal-mode record nil)
  command-execute(normal-mode record)
  helm-M-x(nil "normal-mode")
  call-interactively(helm-M-x nil nil)
  command-execute(helm-M-x)

haskell-cabal-get-setting no longer exists

This function is used in flycheck-haskell-get-config-value, it no longer exists in the latest release of haskell-mode.

Can we have support for stack?

Haskell stack is kind of nice for big projects. It would be cool if flycheck-haskell would support it.

I have hacked some code for that, but I'm out of my dept when it comes to elisp. Anyway, here is the code:

https://github.com/alcidesv/flycheck-haskell

Suggestions are appreciated.

Honor "with-compiler" flag in cabal.config when doing flycheck-haskell-configure

I have 3 different versions of GHC installed on my system currently: the one supported by my OS (7.6.3), the latest stable release (7.8.4), and the latest release candidate (7.10-rc1). I would like to choose which one to use on a per-project basis. using a project local cabal.config enables me to do so for most purposes, even without having a foo.cabal file.

Flycheck partially stopped working

Hello. I've upgraded some packages (I didn't noticed which exactly, sorry) and it seems like flycheck-haskell has stopped to work.

Now if I type import Data.List (sort) even if sort is not used in the file it won't warn me about importing unused function. My test suite doesn't see anymore library package. Packages in sandboxes seem to be invisible as well. Obvious syntax errors are reported, though.

I will try to investigate tomorrow when I have time. Sorry that I don't provide more information right now. I see that this may be not Flycheck's fault because last commit was more than month ago, and I'm upgrading every day, so I would have noticed it before if it were Flycheck.

Is it possible that recent changes in haskell-mode somehow broke flycheck-haskell? Please see their latest commits.

Run 'stack ghc' from project root instead of directory of current file

Yesod ecosystem kinda likes to keep data in separate files (one for config, another one to describe database entities, etc). Then those files are embeded into Haskell modules via file-embed or similar TH magic. Since paths to the files are relative (absolute paths would not be flexible at all), current working directory is really important. This leads to the situation when project compiles fine from command line but Flycheck compilation fails (often without any error messages until I investigate it with flycheck-compile), because it calls stack ghc … from current directory, not project root directory.

My question is how to make Flycheck internally run stack ghc … command from project's root (where Cabal file is found) every time, instead of running it from current directory (where file I edit is located).

I can imagine not everyone is having this sort of problem, so a hint how I can change it just in my configuration would suffice. At the same time, it wouldn't be bad in any sense if stack ghc … ran always from project's root, I don't see any problems with making this behavior default.

I previously tried to work around this issue, but now it begins to be real hassle that I can't handle manually. I'm already having problems with flycheck-haskell because I need to be careful not to upgrade my local version (with changes from #48).

Support GHC8 Error Messages

I've been using the haskell-stack-ghc checker since it was released and I haven't had a single issue. However, GHC 8 seems to have a slightly different error message structure which keeps the error messages from properly showing in the minibuffer.

If I run M-x flycheck-compile RET haskell-stack-ghc manually, the error message looks like this:

/home/me/dev/haskell/keter/Data/Yaml/FilePath.hs:65:29: error:
    Not in scope: type constructor or class ‘PareYamlFile’
    Perhaps you meant ‘ParseYamlFile’ (line 53)

if you need a stack.yaml file to reproduce:

flags:
  keter: {}
packages:
- '.'
extra-deps: []
resolver: nightly-2016-06-02

There are a few other interesting changes to the error messages, I'll post them if they are useful.

flycheck-haskell does not work with haskell-mode installed from source

I'm hacking haskell-mode from time to time and decided to install it from git sources rather than from MELPA PA. Now flycheck-haskell fails to start with following output:

Warning (emacs): Unable to activate package `flycheck-haskell'.
Required package `haskell-mode-13.7' is unavailable

I guess this is because of this¹. But likely it defines minimal required version, so I have no idea what's wrong. Current haskell-mode version is 13.12.

-fno-code does not fly with template haskell

Setup:
SourceWithSomeTHDefinitions.hs
SourceUsingThoseTHDefinitions.hs

When doing flycheck over SourceUsingThoseTHDefinitions.hs it finds and imports SourceWithSomeTHDefinitions.hs properly but the bails out with:

ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
XYziDerive_newtypeDeriveReadShow_closure
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:
[email protected]

Reason: SourceWithSomeTHDefinitions.o wasn't created so Template Haskell could not be loaded.

I guess running without -fno-code is problematic. But when first run fails with ByteCodeLink.lookupCE then a second run without -fno-code could be made. But that requires temporary directory setup. Overall this is not fun.

Cabal-based syntax checker

We should provide an (optional) syntax checker based on cabal build.

Needs flycheck/flycheck#312 implemented first.

Doesn't recognize default-extensions in cabal file

My cabal file contains default-extensions: TemplateHaskell for the project which enables it for any exposed module.

However flycheck gives me this error on a naked expression when the Pragma isn't at the top of the file.

Parse error: naked expression at top level
Perhaps you intend to use TemplateHaskell

Suspicious state from syntax checker haskell-ghc...

Flycheck has ceased to work after a recent update. I have a project my-project that consists of a library and an executable that depends on the library (i.e. depends on my-project). haskell-mode, REPL, etc. work fine, but when I open any file in the project I'm presented with this message in the minibuffer:

Suspicious state from checker haskell-ghc: Checker haskell-ghc returned non-zero exit code 1, but no errors from output: : cannot satisfy -package my-project (use -v for more information) Checker definition probably flawed.

flycheck-haskell-process-configuration should setq not append options

Cabal treats .cabal files as full definitions and usually explicitly resets settings. For example:

$ cabal build -v
/usr/bin/ghc --make -fbuilding-cabal-package -O -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package-name example-cabal-package-0.1.0.0 -hide-all-packages -package-db .cabal-sandbox/x86_64-osx-ghc-7.6.3-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 -package-id bytestring-0.10.0.2-bf7aaeef3f644374cd7d5a9066cd9017 -XHaskell2010 -XOverloadedStrings  Main
[1 of 1] Compiling Main             ( src/Main.hs, dist/build/Main.o )

flycheck should mimic this invocation as closely as possible. Note reset flags:

• -i - clear search paths
• -hide-all-packages - hide all packages (and list visible ones explicitly)
• -XHaskell2010 - default language setting
• (??) what happened to -no-user-package-db (I dimly remember it being there)

General rule: when configuring from cabal flycheck should replace not append to current options set as this is what cabal tries very hard to do.

Add a way to enable/disable packages

I have a package that depends on mtl directly and on monads-tf indirectly. While building under cabal works due to -hide-all-packages -package mtl, under flycheck it does not as all packages are equally visible.

Checker haskell-ghc returned non-zero exit code 1, but no errors from output:
/Sources/MySourceCode.hs:55:18:
Ambiguous module name `Control.Monad.Writer.Strict':
it was found in multiple packages: monads-tf-0.1.0.1 mtl-2.1.2

Checker definition probably flawed.

Support for / use of extensions in .cabal

Hello,

It seems that flycheck is reporting errors without respect to the extensions listed in the .cabal file. For instance I found that mdo-notation was flagged as a parse error regardless of the presence of RecursiveDo in default-extensions. (Adding a {-# language RecursiveDo #-} pragma to the file makes the error go away for that file.) The code can still be loaded into the REPL though.

Conversely flycheck does not complain about, say, use of tuple sections when TupleSections is not enabled. I am newish to writing Haskell in emacs (well, Spacemacs) so my apologies if I've missed something about the syntax checker's behavior.

"Checker definition prob. flawed" after switching Stackage resolver

Flycheck 28, Emacs 24.5.1 x86_64-apple-darwin13.4.0

1. change Stackage resolver (in my case, from lts-5.15 (GHC 7.10.3) to nightly-2016-06-20 (GHC 8.0.1)), retrigger Flycheck
2. Flycheck turns off with the following error message :

Checker definition probably flawed.
Suspicious state from syntax checker haskell-stack-ghc: Checker haskell-stack-ghc returned non-zero 
exit code 1, but no errors from output: After installing Cabal, the package id couldn't be found 
(via ghc-pkg describe Cabal). This shouldn't happen, please report as a bug

1. stack install hlint (even though it was already in $HOME/.local/bin and working just fine under GHC 7.10.3) (I thought the bug was due to hlint being compiled for/by the wrong GHC version)
2. Same error message

Thanks in advance for all pointers

False positive error using embedFile with relative path

I'm Data.FileEmbed like this:

$(embedFile "foo")

This compiles fine, but flycheck reports the file foo doesn't exist. If I specify an absolute path, or if I change foo to ../../../foo, then it doesn't report an errror.

Is there maybe some command that flycheck is running from the directory in which the checked .hs file resides, that should be running instead at the top of the project where the stack/cabal files reside?

flycheck-haskell-configure should be idempotent

As per discussion in #14 flycheck-haskell-configure executed twice should have same result as execute once.

Right now it appends duplicate flags and that might cause issues when flag duplication is important.

Error During Interactive Linking, GHCi Couldn't Find the Following Symbol

I receive the following error when I have flycheck-haskell enabled
and I attempt to use haskell-mode's haskell-process-load-file:

During interactive linking, GHCi couldn't find the following symbol:                
  Settings_staticDir_closure                                                        
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:                             
  [email protected]                                                  


Checker definition probably flawed.

This error is on a basic Yesod site and does not happen on other
(non-yesod) cabal projects. Yesod does use some CPP to conditionally
compile environments but I haven't quite figured out if that's related
to this issue (staticDir is a simple function staticDir = "static").

I'm not certain how to go about debugging this further. Let me know if
there is anything else I can do to help.

Thanks!

let-alist dependency missing ?

i try to install flycheck-haskell using Cask, and i've got this error :

Dependency flycheck-haskell failed to install: Package `let-alist-1.0.1' is unavailable

i've got setup package :

(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
                         ("marmalade" . "http://marmalade-repo.org/packages/")
                         ("org" . "http://orgmode.org/elpa/")
                         ("melpa" . "http://melpa.milkbox.net/packages/")))

Haskell sources are missing in MELPA-stable repo?

I'm using MELPA stable repo and find that all Haskell source files are missing which makes this package unusuable.

You can download the tarball from this page to confirm.

flycheck-haskell doesn't read LANGUAGE options from the .cabal file

When I try to use flycheck-haskell together with Idris, it complains about missing language extensions. This is because we declare the extensions in the .cabal file rather than putting them at the top of each file. It would be really great if flycheck-haskell also read this from the .cabal file so I could use it on Idris - it's great!

cabal sandbox packages not included in GHC command

Right now on Arch Linux, flycheck-haskell is not setting the correct variables for ghc to find the packages. For instance, on a file with import Data.List.Split (splitOn) flycheck fails with could not find module Data.List.Split, just as if flycheck-haskell was not installed / configured. This used to work.

I looked into all the variables set by this package and compared to the actual ghc command used by cabal build and found that it's not using -i flags to tell ghc where to find the packages, but -package-id set to split-0.2.2-204e96694e892969ddc6c0f253af01bd. Once I manually set flycheck-ghc-args to -package-id split-0.2.2-204e96694e892969ddc6c0f253af01bd it correctly found the package.

The fix would be to do what cabal build does and set flycheck-ghc-args to a collection of package-id followed by each package dependency.

stack build command should be done in project root directory

At the moment, the stack ghc command needed to check a file is executed in the directory file instead of the project root. This breaks template haskell function using relative path (example persistWithFile use in Yesod scaffholding).
The project root can be found by running stack path --project-root.

"Suspicious state from syntax checker haskell-stack-ghc"

"[..] Checker haskell-stack-ghc returned non-zero exit code 1, but no errors from output."

I'm using the latest GHC for OSX (ghc 7.10.3), Emacs 24.5.1, and the above error message appears after activating flycheck-mode.

Here are the pertinent section of my init.el

(autoload 'ghc-init "ghc" nil t)
(autoload 'ghc-debug "ghc" nil t)

(add-hook 'haskell-mode-hook (lambda () (ghc-init)))
(add-hook 'haskell-mode-hook 'turn-on-haskell-doc-mode)
(add-hook 'haskell-mode-hook 'turn-on-haskell-indentation)

(eval-after-load 'flycheck
  '(add-hook 'flycheck-mode-hook #'flycheck-haskell-setup))

(custom-set-variables
 '(exec-path
   (quote
    ("/usr/bin" "/bin" "Users/ocramz/.local/bin" "/usr/sbin" "/Applications/ghc-7.10.3.app/Contents/bin" "/sbin" "/Applications/Emacs.app/Contents/MacOS/bin-x86_64-10_9" "/Applications/Emacs.app/Contents/MacOS/libexec-x86_64-10_9" "/Applications/Emacs.app/Contents/MacOS/libexec" "/Applications/Emacs.app/Contents/MacOS/bin")))
 '(haskell-interactive-mode-hide-multi-line-errors nil)
 '(haskell-process-log t)
 '(haskell-process-type (quote auto))
 '(package-archives
   (quote
    (("gnu" . "http://elpa.gnu.org/packages/")
     ("melpa" . "http://melpa-stable.milkbox.net/packages/")
     ("melpa-stable" . "http://stable.melpa.org/packages/")))))
)

`haskell-stack-ghc` is not receiving CPP args, presumably not using cabal?

I just upgraded flycheck as well as moved a project to GHC 8.0.2 (from 7.10.3), and CPP includes are no longer working with the checker. In my case, I define PACT_VERSION in my cabal:

  cpp-options: -DPACT_VERSION="2.2.2"

then have a module just to import this:

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE CPP #-}

module Pact.Types.Version (pactVersion) where

import Data.Text (Text)

pactVersion :: Text
pactVersion = PACT_VERSION

PACT_VERSION shows up as an undefined symbol. Output of flycheck-compile with haskell-stack-ghc:

stack ghc -- -Wall -no-link -outputdir /var/folders/7r/_9jtpk2j0gs7sg89099hxp0r0000gn/T/flycheck-haskell-ghc-cache5748aky -XHaskell2010 -i/Users/stuart/dev/pact/dist/build -i/Users/stuart/dev/pact/dist/build/autogen -i/Users/stuart/dev/pact/dist/build/pact/pact-tmp -i/Users/stuart/dev/pact/dist/build/bench/bench-tmp -i/Users/stuart/dev/pact/.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -i/Users/stuart/dev/pact/.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen -i/Users/stuart/dev/pact/.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/pact/pact-tmp -i/Users/stuart/dev/pact/.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/bench/bench-tmp -i/Users/stuart/dev/pact/src -i/Users/stuart/dev/pact/executables -i/Users/stuart/dev/pact/tests -i/Users/stuart/dev/pact/src/ -Wall -I/Users/stuart/dev/pact/dist/build/autogen -I/Users/stuart/dev/pact/.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen -optP-include -optPcabal_macros.h -hide-all-packages -package Decimal -package aeson -package ansi-wl-pprint -package async -package attoparsec -package base -package base16-bytestring -package blake2 -package bound -package bytestring -package cereal -package containers -package criterion -package data-default -package deepseq -package direct-sqlite -package directory -package ed25519-donna -package exceptions -package fast-logger -package filepath -package hashable -package hspec -package lens -package lens-aeson -package mtl -package old-locale -package optparse-applicative -package parsers -package safe -package safe-exceptions -package scientific -package semigroups -package snap-core -package snap-server -package statistics -package stm -package text -package thyme -package transformers -package trifecta -package unordered-containers -package utf8-string -package vector -package vector-space -package yaml -x hs /Users/stuart/dev/pact/src/Pact/Types/Version.hs
[1 of 1] Compiling Pact.Types.Version ( /Users/stuart/dev/pact/src/Pact/Types/Version.hs, /var/folders/7r/_9jtpk2j0gs7sg89099hxp0r0000gn/T/flycheck-haskell-ghc-cache5748aky/Pact/Types/Version.o )

/Users/stuart/dev/pact/src/Pact/Types/Version.hs:18:15: error:
    Data constructor not in scope: PACT_VERSION :: Text

What you'll note is that the necessary flags are missing. If I do a verbose build from stack (with --cabal-verbose), I see the following:

2017-05-26 13:21:03.749746: [info] /Users/stuart/.stack/programs/x86_64-osx/ghc-8.0.2/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -odir .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -hidir .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -stubdir .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -i -i.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build -isrc -i.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen -I.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen -I.stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build '-optP-DPACT_VERSION="2.2.2"' ...

The -optP-DPACT_VERSION="2.2.2" being the missing thing. If I add that to the command invocation above from flycheck-compile (on the command line) it works.

So it would seem that the flycheck environment is not working properly with the cabal file.

flycheck-haskell-get-cabal-configuration should cache results

I'm working on a project with about 250 hs (Haskell source) files under umbrella of a single .cabal file. I also have the habbit of closing and reopening Haskell files when needed.

flycheck-haskell-get-cabal-configuration takes half a second to execute, not much, but annoying as it is synchronus with main emacs thread. flycheck-haskell-get-cabal-configuration should cache cabal extraction (based on cabal file modification time). For me it is enough to have a cache of 1 place as I'm working with one project.

Alternative solution would be to run flycheck-haskell-configure just before flychecking starts (in background).

Cabal defined CPP macros dont work.

Code like this:

#if MIN_VERSION_monad_control(1, 0, 0)

is highlighted as wrong with such error message:

error: missing binary operator before token "("
#if MIN_VERSION_monad_control(1, 0, 0)

It looks like flycheck-haskell do not take cabal defined macros into account.

PS. Why dont just use cabal build to build modules, or just get all parameters which cabal gives to ghc using e.g. http://hackage.haskell.org/package/cabal-cargs ?

FlyCheck unable to find sandboxed packages

Currently I'm using shared sandbox created by Stackage CLI¹, but I had same problem with normal sandbox. FlyCheck reports me a lot of haskell-ghc checker "Could not find module" errors when checking sandboxed project (output of C-c ! C-c haskell-ghc RET):

-- mode: compilation; default-directory: "~/Haskell/SandBox/" --
Compilation started at Tue May 26 17:52:21

ghc -Wall -fno-code -i/Users/arthurfayzrakhmanov/Haskell/SandBox/ -x hs /Users/arthurfayzrakhmanov/Haskell/SandBox/Foundation.hs

Handler/Form/Import.hs:13:18:
Could not find module ‘Text.Shakespeare.I18N’
Use -v to see a list of the files searched for.

Handler/Form/Import.hs:14:18:
Could not find module ‘Yesod.Core’
Use -v to see a list of the files searched for.

Handler/Form/Import.hs:15:18:
Could not find module ‘Yesod.Form.Fields’
Use -v to see a list of the files searched for.
… and so on

And cabal list --installed from project root makes sure that modules are actually installed:

$ cabal list --installed

…

* shakespeare
    Synopsis: A toolkit for making compile-time interpolated templates
    Default available version: 2.0.5
    Installed versions: 2.0.5
    Homepage: http://www.yesodweb.com/book/shakespearean-templates
    License:  MIT 
…

* yesod-core
    Synopsis: Creation of type-safe, RESTful web applications.
    Default available version: 1.4.9.1
    Installed versions: 1.4.9.1
    Homepage: http://www.yesodweb.com/
    License:  MIT

* yesod-form
    Synopsis: Form handling support for Yesod Web Framework
    Default available version: 1.4.4.1
    Installed versions: 1.4.4.1
    Homepage: http://www.yesodweb.com/
    License:  MIT

…

I guess this is because of checker use ghc -Wall -fno-code -i<path> command; should it use cabal in case of sandboxed projects?

ghc 8.2 stopped checking my buffers

Hi, ghc stopped checking my buffers, but I get no error message why. I use cabal, I have disabled stack, because I don't use it. My ghc version is 8.2

Support new cabal builds

Cabal new-build uses a new dist dir layout, and requires package-db locations in the ghc call. I got it to work with the following changes:

get-cabal-configuration.hs: see commit on my fork d1a7cd8 .

Added package-dbs using .dir-locals for my project. I'm on ghc 8.0.1, and the project is fadno, with the dist dir being dist-newstyle/build/fadno-1.0.0:

(flycheck-ghc-package-databases "/Users/stuart/.cabal/store/ghc-8.0.1/package.db" "/Users/stuart/dev/fadno/dist-newstyle/packagedb/ghc-8.0.1" "/Users/stuart/dev/fadno/dist-newstyle/build/fadno-1.0.0/package.conf.inplace")

Might be nice to get input from @ezyang (or other new-cabal wizards) as to how to do this properly, and how stable this stuff is. For instance, the dist-newstyle stuff is available in cabal-install: https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/DistDirLayout.hs#L110

But not in Cabal library, so not accessible (?) in get-cabal-configuration.hs. DistDirLayout seems to show that this path can be more complex than simply dist-newstyle/build/foo-version/build etc, so not sure how hacky my solution is thus far.

But it does seem that we would want to discover the package-db invocations.

Checking c2hs files

What should I modify to have Haskell linting/typechecking when editing c2hs .chs files (Haskell with C #includes and c2hs {# ... #} macros) ?
The major mode I use for .chs is M-x haskell-c-mode .

I already have FlyCheck working in haskell-mode and C mode sepately.

Thank you in advance

Suspicious state from syntax checker javascript-eslint

I’ve got flycheck configured as per this blog post, but I’m getting the following error code which I’m unable to solve.

Suspicious state from syntax checker javascript-eslint: Checker javascript-eslint returned non-zero exit code 127, but no errors from output: env: node: No such file or directory

Checker definition probably flawed.

If I run eslint manually I don’t get any such errors:

$ eslint /my-file.jsx

/my-file.jsx
  2:7  error  PurchaseDetail is defined but never used    no-unused-vars
  3:7  error  PurchaseForm is defined but never used      no-unused-vars
  4:7  error  DayBudgetDetails is defined but never used  no-unused-vars

✖ 3 problems (3 errors, 0 warnings)

Any ideas?

Handle build directories of executables

E.g. dist/build/foo/foo-tmp …

Don't require stack

Would it please be possible to make stack usage optional?

Whilst I have stack installed (and hence the default for flycheck-haskell-runghc-command uses it), I'm not actually using it for my day-to-day development. As such, I frequently get spurious errors because stack doesn't know about a module since I installed it using cabal sandboxes.

Flycheck crash my Emacs

When I run Interactive-Haskell with next .ghci

:set -package funnyprint

:def color (\_ -> return (":set -interactive-print=FunnyPrint.funnyPrint\n:set prompt \"" ++ FunnyPrint.prompt "λ " "%s" " ¬\\nλ > " ++ "\"" ++ "\n:set prompt2 \"" ++ FunnyPrint.prompt2 "λ" "" " | " ++ "\""))
:def nocolor (\_ -> return ":set -interactive-print=print\n:set prompt \"%s> \"\n:set prompt2 \"%s| \"")

After I run :color in Interactive-Haskell session to enable colorful output, and switch back to haskell-mode buffer, Eldoc (or what?) stuck, trying to show me type for function under cursor, and Emacs crash.

flycheck-haskell-configure won't be called if `enable-local-variables` is nil

After configure

(eval-after-load 'flycheck
  '(add-hook 'flycheck-mode-hook #'flycheck-haskell-setup))

I notice cabal sandbox config takes no effect for flycheck-haskell. Manually call flycheck-haskell-configure will fix this problem.

Looking into the flycheck-haskell-setup and hack-local-variables-hook

 (add-hook 'hack-local-variables-hook #'flycheck-haskell-configure)

I found with enable-local-variables set to nil, the hack-local-variables-hook will never be called.

Add check for this?

flycheck fails parsing preprocessor directives

If file contains directives like:

module Settings.Development where

import Prelude

development :: Bool
development =
#if DEVELOPMENT
  True
#else
  False
#endif

production :: Bool
production = not development

It fails with the following error:

Checker haskell-ghc returned non-zero exit code 1, but no errors from output: [1 of 4] Compiling Settings.Development ( Settings/Development.hs, nothing )

Settings/Development.hs:7:2: lexical error at character 'i'

flycheck-haskell fails when sandbox isn't present

At least, I don't use sandboxes, and the reference to package-db in the error message:

Error while checking syntax automatically: (error "Value (nil) of flycheck-ghc-package-databases for option \"-package-db\" is not a list of strings") [10 times]

(which seems only used with sandboxes) would seem to point the finger at the sandbox support.

I created #35 to resolve this.

Cabal sandbox not being used

My user package database has transformers-0.3 and my sandbox package database has transformers-0.4 but flycheck-haskell is transformers-0.3 and incorrectly reporting errors. I suspect the user package database is taking precedence over the sandbox package db but it shouldn't.

get-cabal-configuration returning wrong version of stack build directory

I've updated cabal-install to 1.22.8 using cabal install cabal (or equivalent, I don't remember exactly the command) and this break flycheck : I get a can't find cabal_macros.h. The reason is get-cabal-configuration.hs generate the path to find this file in .stack-work/dist/x86_64-linux/Cabal-1.22.8.0/build/autogen but this directory doesn't exist but is .stack-work/dist/x86_64-linux/Cabal-1.22.5./build/autogen instead. Basically stack doesn't know I've upgraded cabal to 1.22.8. and still use 1.22.5.

The workaround is to upgrade the stack setup with stack setup --upgrade-cabal .
The correct way to find the stack dist directory seems to be using stack path --dist-dir.

Stack based syntax checker

Use stack build for syntax checking.

Read dist/setup-config

After .cabal project is configured it create a configuration file in dist/setup-config. It contains all information needed:

• which compiler should be used (full path)
• what options (for example warnings selection)
• visible packages
• etc

It contains all the information that would allow to flycheck with exactly same compiler and flags as later compilation.

It is rather easy to read that file using current helpers/get-xxxx.hs machinery. The problem is it produces a lot of information that would result in many flycheck-ghc-xxxx-option flags. This is not good as those flags need to be declared in flycheck.el but populated in flycheck-haskell.el (in flycheck-haskell-configure).

Any idea wher to stuff this information?

Opening a large project from a desktop file leads to fork-bomb

flycheck-haskell appears to start a GHC process for each source file it loads with no sort of rate-limiting. When loading a large project this leads to an extremely high number of processes being spawned, to the point where the stability of the host system can be jeopardized.

It seems like some rate-limited work-queue would be appropriate here.

Flycheck doesn't work with Stack project

I'm editing files of Stack:

https://github.com/commercialhaskell/stack

and this is quite big project, of course. I've noticed that Flycheck works fine for modules in src/Stack/Types/ and doesn't work at all for src/Stack/Fetch.hs for example. Maybe this is because the latter depends on more modules? I don't know. Is there any limitations on Flycheck usability? Should it work with projects of this size?

Strange and weird things are happening

Our current approach with passing --hide-all-packages and then selecting them with -package arguments may be flawed, or it's a bug on the Stack side. The problem is desribed here:

commercialhaskell/stack#1684

In short, Stack somehow uses several versions of the same package and even several different versions of the same package when called via stack ghc with arguments specifyng package names, it seems.

If anyone is fighting this too, please comment, so I know that I'm not going crazy here.

---

I do not request any action from @lunaryorn, because I think it's Stack's problem and current approach should work well in theory.

flycheck-cask intrustructions in readme file

Readme file is copy paste from flycheck-cask :)

Installation

As usual, from MELPA and Marmalade.

In your Cask file:

(source gnu)
(source melpa)

(depends-on "flycheck-cask")

In your init.el:

(eval-after-load 'flycheck
'(add-hook 'flycheck-mode-hook #'flycheck-cask-setup))

flycheck-haskell breaks with library-vanilla:false and shared:true, executable-dynamic:true under cabal sandbox

Consider the following under ~/.cabal/config:

library-vanilla: False
shared: True
executable-dynamic: True

With cabal sandbox for building some package (ghc 7.8.3) and the settings above, imports of the package fail during during flycheck's run.

I switched off library-vanilla back to the default of True, rebuilt the cabal sandbox and it fixed it. So I am guessing that the ghc invocation did not receive the right parameters for loading the shared library builds.

(EDITS: fixes)