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

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 wrote:

I'm in favour.

On Wed, 13 Mar 2024 at 08:50, Moritz Angermann mailto:moritz.angermann@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 mailto:simon.peytonjones@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 mailto:chris@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/prop... 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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee