runghc -fdefer-type-errors

[Gabriel Dos Reis]

On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree
<ml at isaac.cedarswampstudios.org> wrote:
> On 03/11/2013 07:04 PM, Simon Peyton-Jones wrote:
>> Aha.  It is indeed true that
>>
>> ghc -fdefer-type-errors -w
>>
>> does not suppress the warnings that arise from the type errors;
>> indeed there is no current way to do so.  How to do that?
>>
>> To be kosher there should really be a flag to switch off those
>> warnings alone, perhaps -fno-warn-type-errors
>>
>> So then -fwarn-type-errors is on by default, but is only relevant
>> when -fdefer-type-errors is on.  Once -fdefer-type-errors is on,
>> -fno-warn-type-errors and -fwarn-type-errors suppress or enable the
>> warnings.  -w would then include -fno-warn-type-errors.
>
> GCC has a concept -Werror=unused-variable for example: each
> warning can be disabled, a warning, or an error.  If GHC had that, we
> could have "type-errors" be a warning whose default state is -Werror.
> That's cleaner in a certain way, but it also seems fishy.  Just
> throwing the idea out there.

I don't know which way GHC would like to go, but I can comment on the
GCC feature as I have direct experience here.

For a long time I was very reluctant to the fine-grained warning categories;
rather I preferred a much coarser grained warning categories; my thinking was
that "warnings or questionable coding practices" come in cluster (I still do.)
Remember that the more nobs you give user to control the compiler, the larger
your test matrix becomes and the higher is the probability of untested
and/or incoherent compiler switch combinations.

However, several fellow GCC developers felt otherwise -- many citing the
pressure of the "competition" (e.g. icc, clang, etc.), so I eventually gave in
but under the condition that we still maintain the coarse-grained warning
categories (e.g. -Wall, -Wextra, etc.) and display in the diagnostics how
users are to turn off a specific warning they did not like.   I suspect that
if users frequently need to turn off a warning, then that warning should
probably be off by default.

Most users rarely want to specify long (and arcane) command lines; very
few want to litter their otherwise pretty programs with lines of pragmas
(no matter how much effort was spent in designing the syntax.)

-- Gaby