Warning suppression pragmas

[Эдгар Жаворонков]

Hi devs!

I edited wiki page [1] with my proposal about more than week ago. The main
idea is that we mark functins with pragma and filter all warnings that it
will throw. Although it is the question of bad design, i think users, who
have to support old libraries will find this helpful.

I don't know about suppressing specific kinds of warnings. I think, that it
would be more precise to filter them in one place instead of many.

Can someone review it? Sorry for bothering, if any

[1] - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas

---
С уважением,
Жаворонков Эдгар

Best regards,
Edgar A. Zhavoronkov

2015-12-03 15:16 GMT+03:00 Ben Gamari <ben at smart-cactus.org>:

> Эдгар Жаворонков <edzhavoronkov at gmail.com> writes:
>
> > Hello devs!
> >
> > I am trying to implement some kind of local warnings suppresion and i
> need
> > some help.
> >
> > I want to use a pragma to mark functions so compiler won't throw warnings
> > from them. I defined my pragma in lexer, parser and added type signature
> in
> > HsBinds.hs. And i am stuck. I don't know what to do. What should i
> consider
> > doing further?
> >
> I think it would be helpful to focus on further elaborating the
> specification before we move into the implementation. There are still a
> number of open questions about the design that the wiki page doesn't yet
> address.
>
> For instance, you should explicitly specify,
>
>  * What are the identifiers that appear after the `SUPPRESS` token?
>
>  * What exactly does the pragma apply to? For instance, if I have a case
>    like,
>
>        hello :: Int -> Int
>        {-# SUPPRESS some-warning #-}
>        helloAgain :: Type -> AnotherType
>        hello = (+1)
>        helloAgain = error "42"
>
>    or even just
>        hello = (+1)
>        {-# SUPPRESS another-warning #-}
>        helloAgain = error "oops"
>
>    What do you expect to happen? The behavior of the pragma in both of
>    these cases should be unambiguously stated in the specification.
>
>  * An concrete use-case motivating the change (preferably with examples
>    showing how the proposed syntax would address the motivation)
>
> I know this sounds repetitive, but the act of writing down a proposal
> will help you immensely when you do move on to implementing your ideas.
>
> Thanks for your persistence.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/a5906475/attachment.html>