search

rikvdkleij / intellij-haskell

IntelliJ plugin for Haskell
https://rikvdkleij.github.io/intellij-haskell/
Apache License 2.0
1.31k stars 96 forks source link

incomplete-record-updates warning without having it activated #635

Open mrArkwright opened 3 years ago

mrArkwright commented 3 years ago

I'm getting incomplete-record-updates warnings in the editor despite not having that warning activated in my package.yaml. As expected if I run stack build I don't get these warnings.

When adding ghc-options: -Wincomplete-record-updates to the package.yaml stack build does output the warnings accordingly.

I would expect intellij-haskell to pick up the warning configuration from the project and only show the warnings that are configured.

The plugin log shows that the repl is started with:

[project-stack-repl-Foo:lib] REPL will be started with command: /usr/local/bin/stack repl Foo:lib --no-build --ghci-options -ghci-script=/Users/jnk/Library/Caches/com.github.rikvdkleij.intellij-haskell/repl.ghci --silent --ghc-options "-v1 -Wall -Wcompat -Wincomplete-record-updates -Wincomplete-uni-patterns -Wredundant-constraints"

Is there a particular reason that these particular ghc options are used (which are overriding the projects settings)?

rikvdkleij commented 3 years ago

Is there a particular reason that these particular ghc options are used (which are overriding the projects settings)?

Yes because some of the plugin features depend on the error/warning messages of GHC. So I decided to enable the recommended GHC options by default. You can change them in Haskell Settings.

mrArkwright commented 3 years ago

Thanks for the pointer! That does indeed solve my problem.

I would still argue that it's a bad idea to have the plugin override the project settings by default. That's surprising behaviour (at least for me it was). The right place to configure ghc-options is the package.yaml or cabal file. I think there are no situations in which you would want the plugin display different warnings than a stack build in the terminal. Or am I missing something here?

It's also important to have the settings per project and not system wide for the whole plugin. Different projects (even different subprojects) might use different settings. The package.yaml/cabal file solution provides this.

Default GHC options should be configured in the moment the project is created. So that's up to stack new if that's what the plugin uses.

rikvdkleij commented 3 years ago

In theory you're right and I also had this opinion for a long time. But I noticed that users were missing features because they didn't enable e.g. -Wall. So e.g. that didn't had the intention action to add type signature to top-level definition. So eventually I came with this solution. But yeah, it's disputable.