Loading modules despite type errors and correct handling of errors cast via -Werror

[VerKWer]

With the default configurations, when opening a project that contains errors (which obviously happens frequently during development), Intero fails to load any modules and becomes pretty much useless. Operations such as looking up types or jumping to definitions won't work and instead report

Couldn't guess the module name. Is this module loaded?

A way to avoid this is to put the following line in .config/nvim/init.vim (a.k.a. .vimrc):

let g:intero_ghci_options = "-fdefer-type-errors -Werror=deferred-type-errors"

(see ticket [#84]). With the first flag, we continue compilation upon encountering type errors and just output a warning instead, while the second flag "recasts" those warnings into errors. This opens up the new problem that the resulting error message has an unrecognised format:

... error: [-Wdeferred-type-errors, -Werror=deferred-type-errors]

(which was also mentioned in ticket [#84]). This is easily fixable by adding

'%E%f:%l:%c:\ error:\ [%.%#-Werror%.%#]%#,'

to the s:efm variable in the plugin/intero.vim file. With this in mind, I have two suggestions:

1. Because casting warnings to errors (via the -Werror or -Werror=... flags) is a generic feature of ghc (and not specific to the problem described above), I think this error format should be recognised by default.
2. Failing to load anything if there are errors doesn't seem very user-friendly and maybe the two flags suggested above should be the default? I'm not really well-versed with -fdefer-type-errors and maybe there are some performance reasons that speak against it. This was already discussed in ticket [Ability to inspect when code doesn't type-check #84] but it seems like no conclusion was reached.

[VerKWer]

So it seems like I wasn't careful enough with my tests (and probably forgot to save some edited file at some point). Turns out that passing -Werror=deferred-type-errors will also keep the modules from being loaded. I assumed it was mostly a difference in reporting but it turns out that the specified warning will be interpreted as a fatal error (the documentation even says so...) and leads to failure. Still, my point 1 above stands and it only takes one changed line to support this feature and report these errors properly.

As a workaround for the original issue, one can simply put

let g:intero_ghci_options = '-fdefer-type-errors'

in the .vimrc-file (so that compilation doesn't stop upon encountering type errors). To report any warnings arising from it as errors, one then adds

'%E%f:%l:%c:\ warning:\ [-Wdeferred-type-errors],'

to the s:efm-variable. This is a bit ugly because ideologically speaking, one doesn't want to report warnings as errors but this is the best short-term solution I could think of.