Re: runghc -fdefer-type-errors
Gabriel Dos Reis <gdr <at> integrable-solutions.net>
2013-03-12 23:25:32 GMT
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.)