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

[Chris Dornan]

There have been no objections to this (fine-grained warnings) proposal which has been broadly supported through a couple of rounds of voting so I have marked it and marked it as accepted.

Thanks everyone.

Chris

> On 14 Mar 2024, at 07:58, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I'm in favour.
> 
> On Wed, 13 Mar 2024 at 08:50, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> 
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20240419/29fb4acd/attachment-0001.html>