This looks like a good change to me. There is no discussion around the breaking implications of this, and only Joachim seems to havecalled them out. E.g. tooling that tries to read GHC's human readable output, and do something with that. The improved clarity of theerror messages though is arguably enough. And as far as breakage is concerned, this would only happen to tools that use already afragile pass parsing log output of another program. I hope this won't cause too much trouble down the line, and am I favour of thisproposal._______________________________________________On Wed, 13 Mar 2024 at 00:51, Simon Peyton Jones <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 <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/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@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
ghc-steering-committee mailing list
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
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee