Open VerKWer opened 5 years ago
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.
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
A way to avoid this is to put the following line in
.config/nvim/init.vim
(a.k.a..vimrc
):(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:
(which was also mentioned in ticket [#84]). This is easily fixable by adding
to the
s:efm
variable in theplugin/intero.vim
file. With this in mind, I have two suggestions:-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.-fdefer-type-errors
and maybe there are some performance reasons that speak against it. This was already discussed in ticket [#84] but it seems like no conclusion was reached.