Add 'warnings' field to configuration

[chshersh]

There're some warnings which are not included in -Wall but some people think they should be used anyway. I think we should create special configuration field for this. And add some fields to our default config.

Source:

• https://www.reddit.com/r/haskell/comments/6q9tcp/ghc_warnings_you_should_use_in_addition_to_wall/

Comments are interesting as well.

[chshersh]

I propose to add the following warnings by default:

• -Wincomplete-uni-patterns
• -Wincomplete-record-updates
• -Wmissing-import-lists
• -Wcompat
• -Widentities
• -Wredundant-constraints (since 8.0)
• -Wmissing-export-lists (since 8.4.1)
• -Wpartial-fields (since 8.4.1)

List of all GHC warnings can be found here:

• https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-warnings.html

[chshersh]

@willbasky This task is about only adding warnings fields to configuration. You should this extra field to configuration here:

summoner/src/Summoner/Config.hs

Lines 45 to 65 in 96b1033

	-- | Potentially incomplete configuration.
	data ConfigP (p :: Phase) = Config
	{ cOwner :: p :- Text
	, cFullName :: p :- Text
	, cEmail :: p :- Text
	, cLicense :: p :- License
	, cGhcVer :: p :- [GhcVer]
	, cCabal :: Decision
	, cStack :: Decision
	, cGitHub :: Decision
	, cTravis :: Decision
	, cAppVey :: Decision
	, cPrivate :: Decision
	, cScript :: Decision
	, cLib :: Decision
	, cExe :: Decision
	, cTest :: Decision
	, cBench :: Decision
	, cPrelude :: Last CustomPrelude
	, cExtensions :: [Text]
	} deriving (Generic)

And then you should use it to populate ghc-options field in .cabal files.

[willbasky]

Will warnings add to configuration if there is --file conf.toml or\and if there is user's yes in interactive mode?

[chshersh]

@willbasky We have this note in README about priority order:

• https://github.com/kowainik/summoner#usage

But personally I think that it doesn't make much sense to ask about warnings interactively. We already add -Wall by default and this should be enough in 99.9% cases. For those who want extra warnings, it's better to specify them in configuration because names on warnings are very long. And it's not convenient to type them manually. So I expect that nobody will write warnings in interactive mode.

But I think that it's a good idea to be able to specify them through CLI options.

[willbasky]

I agree with you. If someone will want to change warnings it easy to rewrite them in text mode after project created.

[vrom911]

I don't entirely agree about CLI part. I guess it's almost the same as with pragmas, better to use config files for that.

[chshersh]

@vrom911 Yeah, that makes sense as well. Probably it's better to not allow them as CLI as well.