[ghc-steering-committee] Fine-Grained Unused Warnings (#343)

Moritz Angermann moritz.angermann at gmail.com
Wed Mar 13 07:50:17 UTC 2024


This looks like a good change to me. There is no discussion around the
breaking implications of this, and only Joachim seems to have
called them out. E.g. tooling that tries to read GHC's human readable
output, and do something with that. The improved clarity of the
error messages though is arguably enough. And as far as breakage is
concerned, this would only happen to tools that use already a
fragile pass parsing log output of another program. I hope this won't cause
too much trouble down the line, and am I favour of this
proposal.

On Wed, 13 Mar 2024 at 00:51, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support this.  I worked a lot with the author to make the spec precise.
> (It was pretty confusing and incomplete before.)
>
> TL;DR: the intent is clear and useful; the details are actually
> surprisingly tricky.  But (like type inference) users won't really care!
>
> Simon
>
> On Tue, 12 Mar 2024 at 16:39, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Folks,
>>
>> Proposal: Fine-Grained Unused Warnings (#42)
>> Author: Jakob Brünker
>> Rendered proposal:
>> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>> Recommendation: Acceptance
>>
>> ## Summary
>>
>> The proposal partitions warning about unused identifiers into
>>
>> a) bindings that are truly unused (not mentioned anywhere) and
>> b) bindings that are mentioned exclusively in code that is itself
>> (transitively) unused,
>>
>> and controls the latter with the new flag -Windirectly-unused-binds,
>> which is enabled by default (to preserve existing behaviour).
>>
>> Everybody seems to be in favour of the proposal in general and it has
>> been extensively revised for clarity and to ensure in interoperates
>> consistently with the existing warning-flags mechanisms.
>>
>> I propose that we accept this proposal if nobody objects by the start of
>> next week (Monday, 2024-03-18).
>>
>> Chris
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240313/d754c74a/attachment-0001.html>


More information about the ghc-steering-committee mailing list