Warnings, -Wall, and versioning policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Warnings, -Wall, and versioning policy

Simon Marlow-7
Hi folks,

We haven't described what guarantees GHC provides with respect to -Wall
behaviour across versions, and as a result there are some differing
expectations around this.  It came up in this weeks' GHC meeting, so we
thought it would be a good idea to state the policy explicitly.  Here it is:

   We guarantee that code that compiles with no warnings with -Wall
   ("Wall-clean") and a particular GHC version, on a particular
   platform, will be Wall-clean with future minor releases of the same
   major GHC version on the same platform.

(we plan to put this text in the User's Guide for future releases)

There are no other guarantees.  In particular:
- In a new major release, GHC may introduce new warnings into -Wall,
and/or change the meaning of existing warnings such that they trigger
(or not) under different conditions.
- GHC may generate different warnings on different platforms. (examples
of this are -fwarn-overflowed-literals and
-fwarn-unsupported-calling-conventions)

Some rationale:
- We consider any change to the language that GHC accepts to be a
potentially code-breaking change, and subject to careful scrutiny. To
extend this to warnings would be a *lot* of work, and would make it
really difficult to introduce new warnings and improve the existing ones.
- Warnings can be based on analyses that can change in accuracy over
time. The -fwarn-unused-imports warning has changed a lot in what it
rejects, for example.
- We often introduce new warnings that naturally belong in -Wall. If
-Wall was required to be a fixed point, we would have to start
introducing new flags, and versioning, etc. and even keep the old
implementation of warnings when they change. It would get really messy.

There are some consequences to this.  -Wall -Werror is useful for
keeping your code warning-clean when developing, but shipping code with
these options turned on in the build system is asking for trouble when
building your code with different GHC versions and platforms.  Keep
those options for development only.  Hackage already rejects packages
that include -Wall for this reason.

One reason we're raising this now is that it causes problems for the
3-release policy
(https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which
requires that it be possible to write code that is Wall-clean with 3
major releases of GHC.  GHC itself doesn't guarantee this, so it might
be hard for the core libraries committee to provide this guarantee.  I
suggest this requirement be dropped from the policy.

Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings, -Wall, and versioning policy

Gershom Bazerman
Hi Simon. I think you raise important issues here, although I believe you’re mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects -Wall.

 What I’d suggest is perhaps the following.

1) The libraries committee put forward -Wall cleanliness as an _aspirational goal_ rather than a final product, noting that the actual cleanliness might be with regards to `-Wall -Wno-foo -Wno-bar``.

2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather than an _error_ on `-W` followed by an unrecognized string.

3) No warning flags be introduced into the _default_ set without at least a few releases in some other set such as `-Wall`.

We may also want to try to maintain a “best practices” example cabal file that shows how one can build with additional warnings under a “dev” flag, and with fewer warnings otherwise — so that the noise inflicted on package devs under their builds doesn’t get inflicted on all end users, and even perhaps with different warning flags per ghc version flag.

I think this will respect the concerns of people that like to use `-Wall`, want to have relatively warning clean code, and want to have some degree of backwards compatibility (which is not an unreasonable combination in my opinion).

Some related discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings

Cheers,
Gershom


On January 12, 2016 at 11:18:57 AM, Simon Marlow ([hidden email]) wrote:

> Hi folks,
>  
> We haven't described what guarantees GHC provides with respect to -Wall
> behaviour across versions, and as a result there are some differing
> expectations around this. It came up in this weeks' GHC meeting, so we
> thought it would be a good idea to state the policy explicitly. Here it is:
>  
> We guarantee that code that compiles with no warnings with -Wall
> ("Wall-clean") and a particular GHC version, on a particular
> platform, will be Wall-clean with future minor releases of the same
> major GHC version on the same platform.
>  
> (we plan to put this text in the User's Guide for future releases)
>  
> There are no other guarantees. In particular:
> - In a new major release, GHC may introduce new warnings into -Wall,
> and/or change the meaning of existing warnings such that they trigger
> (or not) under different conditions.
> - GHC may generate different warnings on different platforms. (examples
> of this are -fwarn-overflowed-literals and
> -fwarn-unsupported-calling-conventions)
>  
> Some rationale:
> - We consider any change to the language that GHC accepts to be a
> potentially code-breaking change, and subject to careful scrutiny. To
> extend this to warnings would be a *lot* of work, and would make it
> really difficult to introduce new warnings and improve the existing ones.
> - Warnings can be based on analyses that can change in accuracy over
> time. The -fwarn-unused-imports warning has changed a lot in what it
> rejects, for example.
> - We often introduce new warnings that naturally belong in -Wall. If
> -Wall was required to be a fixed point, we would have to start
> introducing new flags, and versioning, etc. and even keep the old
> implementation of warnings when they change. It would get really messy.
>  
> There are some consequences to this. -Wall -Werror is useful for
> keeping your code warning-clean when developing, but shipping code with
> these options turned on in the build system is asking for trouble when
> building your code with different GHC versions and platforms. Keep
> those options for development only. Hackage already rejects packages
> that include -Wall for this reason.
>  
> One reason we're raising this now is that it causes problems for the
> 3-release policy
> (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which
> requires that it be possible to write code that is Wall-clean with 3
> major releases of GHC. GHC itself doesn't guarantee this, so it might
> be hard for the core libraries committee to provide this guarantee. I
> suggest this requirement be dropped from the policy.
>  
> Cheers,
> Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>  

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Warnings, -Wall, and versioning policy

Simon Peyton Jones
Thanks Gershom.  That all sounds fine to me.  

An implication is that GHC is free to introduce new warnings X into -Wall.   Indeed doing so would be good, because the warning X might later move into the default set.  Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change.  Then you can use -Wall and look for any "PS" indicators.

You don’t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over.  Worth articulating the rationale.

Simon

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| [hidden email]] On Behalf Of Gershom B
| Sent: 13 January 2016 02:20
| To: GHC users <[hidden email]>; [hidden email];
| Edward Kmett <[hidden email]>; Herbert Valerio Riedel <[hidden email]>; Simon
| Marlow <[hidden email]>
| Subject: Re: Warnings, -Wall, and versioning policy
|
| Hi Simon. I think you raise important issues here, although I believe you’re
| mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
| -Wall.
|
|  What I’d suggest is perhaps the following.
|
| 1) The libraries committee put forward -Wall cleanliness as an _aspirational
| goal_ rather than a final product, noting that the actual cleanliness might
| be with regards to `-Wall -Wno-foo -Wno-bar``.
|
| 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| than an _error_ on `-W` followed by an unrecognized string.
|
| 3) No warning flags be introduced into the _default_ set without at least a
| few releases in some other set such as `-Wall`.
|
| We may also want to try to maintain a “best practices” example cabal file
| that shows how one can build with additional warnings under a “dev” flag, and
| with fewer warnings otherwise — so that the noise inflicted on package devs
| under their builds doesn’t get inflicted on all end users, and even perhaps
| with different warning flags per ghc version flag.
|
| I think this will respect the concerns of people that like to use `-Wall`,
| want to have relatively warning clean code, and want to have some degree of
| backwards compatibility (which is not an unreasonable combination in my
| opinion).
|
| Some related
| discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has
| kell.org/trac/ghc/wiki/Design/Warnings
|
| Cheers,
| Gershom
|
|
| On January 12, 2016 at 11:18:57 AM, Simon Marlow ([hidden email]) wrote:
| > Hi folks,
| >
| > We haven't described what guarantees GHC provides with respect to -Wall
| > behaviour across versions, and as a result there are some differing
| > expectations around this. It came up in this weeks' GHC meeting, so we
| > thought it would be a good idea to state the policy explicitly. Here it is:
| >
| > We guarantee that code that compiles with no warnings with -Wall
| > ("Wall-clean") and a particular GHC version, on a particular
| > platform, will be Wall-clean with future minor releases of the same
| > major GHC version on the same platform.
| >
| > (we plan to put this text in the User's Guide for future releases)
| >
| > There are no other guarantees. In particular:
| > - In a new major release, GHC may introduce new warnings into -Wall,
| > and/or change the meaning of existing warnings such that they trigger
| > (or not) under different conditions.
| > - GHC may generate different warnings on different platforms. (examples
| > of this are -fwarn-overflowed-literals and
| > -fwarn-unsupported-calling-conventions)
| >
| > Some rationale:
| > - We consider any change to the language that GHC accepts to be a
| > potentially code-breaking change, and subject to careful scrutiny. To
| > extend this to warnings would be a *lot* of work, and would make it
| > really difficult to introduce new warnings and improve the existing ones.
| > - Warnings can be based on analyses that can change in accuracy over
| > time. The -fwarn-unused-imports warning has changed a lot in what it
| > rejects, for example.
| > - We often introduce new warnings that naturally belong in -Wall. If
| > -Wall was required to be a fixed point, we would have to start
| > introducing new flags, and versioning, etc. and even keep the old
| > implementation of warnings when they change. It would get really messy.
| >
| > There are some consequences to this. -Wall -Werror is useful for
| > keeping your code warning-clean when developing, but shipping code with
| > these options turned on in the build system is asking for trouble when
| > building your code with different GHC versions and platforms. Keep
| > those options for development only. Hackage already rejects packages
| > that include -Wall for this reason.
| >
| > One reason we're raising this now is that it causes problems for the
| > 3-release policy
| >
| (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
| ll.org%2fwiki%2fLibraries%2f3-Release-
| Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
| 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
| khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
| > requires that it be possible to write code that is Wall-clean with 3
| > major releases of GHC. GHC itself doesn't guarantee this, so it might
| > be hard for the core libraries committee to provide this guarantee. I
| > suggest this requirement be dropped from the policy.
| >
| > Cheers,
| > Simon
| > _______________________________________________
| > Glasgow-haskell-users mailing list
| > [hidden email]
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
| 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
| qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
| >
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| [hidden email]
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
| 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
| fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Warnings, -Wall, and versioning policy

Gershom Bazerman
On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
<[hidden email]> wrote:

> An implication is that GHC is free to introduce new warnings X into -Wall.   Indeed doing so would be good, because the warning X might later move into the default set.  Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change.  Then you can use -Wall and look for any "PS" indicators.

Yep. In general I think we don't know how _much_ noise a warning will
create until it makes it into the wild, so just as with other new
features its good to give them a bit of a "dry run" before deciding
that they come "by default."

> You don’t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over.  Worth articulating the rationale.

Yes, that's exactly the rationale. It doesn't help us short term, but
longer term it should let users fiddle with warning flags more freely.

I think the general issue with three releases is not whether or not
GHC introduces warnings and at what pace, but that certain _types_ of
warnings (in particular redundancies, be they constraints, imports,
etc) will fire on entirely desirable code due to certain migration
paths. Most of the tricks we developed for backwards-compatible
migrations essentially depend on certain redundancies in code for a
period. Those can't be removed without hurting backwards-compatibility
of code, but their presence also induces warnings.

So as a whole "warning freeness" and "backwards compatible migrations"
become increasingly at odds with one another.

A full refactor of our warning sets would probably help in this
regard, so that the default advice could be "good code is -Wlint clean
but not necessarily -Wpedantic clean". Or even "is clean under
-Wpedantic -Wno-redundancies".

--Gershom

>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | [hidden email]] On Behalf Of Gershom B
> | Sent: 13 January 2016 02:20
> | To: GHC users <[hidden email]>; [hidden email];
> | Edward Kmett <[hidden email]>; Herbert Valerio Riedel <[hidden email]>; Simon
> | Marlow <[hidden email]>
> | Subject: Re: Warnings, -Wall, and versioning policy
> |
> | Hi Simon. I think you raise important issues here, although I believe you’re
> | mistaken in one regard. Hackage rejects -Werror but I don’t think it rejects
> | -Wall.
> |
> |  What I’d suggest is perhaps the following.
> |
> | 1) The libraries committee put forward -Wall cleanliness as an _aspirational
> | goal_ rather than a final product, noting that the actual cleanliness might
> | be with regards to `-Wall -Wno-foo -Wno-bar``.
> |
> | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
> | than an _error_ on `-W` followed by an unrecognized string.
> |
> | 3) No warning flags be introduced into the _default_ set without at least a
> | few releases in some other set such as `-Wall`.
> |
> | We may also want to try to maintain a “best practices” example cabal file
> | that shows how one can build with additional warnings under a “dev” flag, and
> | with fewer warnings otherwise — so that the noise inflicted on package devs
> | under their builds doesn’t get inflicted on all end users, and even perhaps
> | with different warning flags per ghc version flag.
> |
> | I think this will respect the concerns of people that like to use `-Wall`,
> | want to have relatively warning clean code, and want to have some degree of
> | backwards compatibility (which is not an unreasonable combination in my
> | opinion).
> |
> | Some related
> | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has
> | kell.org/trac/ghc/wiki/Design/Warnings
> |
> | Cheers,
> | Gershom
> |
> |
> | On January 12, 2016 at 11:18:57 AM, Simon Marlow ([hidden email]) wrote:
> | > Hi folks,
> | >
> | > We haven't described what guarantees GHC provides with respect to -Wall
> | > behaviour across versions, and as a result there are some differing
> | > expectations around this. It came up in this weeks' GHC meeting, so we
> | > thought it would be a good idea to state the policy explicitly. Here it is:
> | >
> | > We guarantee that code that compiles with no warnings with -Wall
> | > ("Wall-clean") and a particular GHC version, on a particular
> | > platform, will be Wall-clean with future minor releases of the same
> | > major GHC version on the same platform.
> | >
> | > (we plan to put this text in the User's Guide for future releases)
> | >
> | > There are no other guarantees. In particular:
> | > - In a new major release, GHC may introduce new warnings into -Wall,
> | > and/or change the meaning of existing warnings such that they trigger
> | > (or not) under different conditions.
> | > - GHC may generate different warnings on different platforms. (examples
> | > of this are -fwarn-overflowed-literals and
> | > -fwarn-unsupported-calling-conventions)
> | >
> | > Some rationale:
> | > - We consider any change to the language that GHC accepts to be a
> | > potentially code-breaking change, and subject to careful scrutiny. To
> | > extend this to warnings would be a *lot* of work, and would make it
> | > really difficult to introduce new warnings and improve the existing ones.
> | > - Warnings can be based on analyses that can change in accuracy over
> | > time. The -fwarn-unused-imports warning has changed a lot in what it
> | > rejects, for example.
> | > - We often introduce new warnings that naturally belong in -Wall. If
> | > -Wall was required to be a fixed point, we would have to start
> | > introducing new flags, and versioning, etc. and even keep the old
> | > implementation of warnings when they change. It would get really messy.
> | >
> | > There are some consequences to this. -Wall -Werror is useful for
> | > keeping your code warning-clean when developing, but shipping code with
> | > these options turned on in the build system is asking for trouble when
> | > building your code with different GHC versions and platforms. Keep
> | > those options for development only. Hackage already rejects packages
> | > that include -Wall for this reason.
> | >
> | > One reason we're raising this now is that it causes problems for the
> | > 3-release policy
> | >
> | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
> | ll.org%2fwiki%2fLibraries%2f3-Release-
> | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
> | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
> | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
> | > requires that it be possible to write code that is Wall-clean with 3
> | > major releases of GHC. GHC itself doesn't guarantee this, so it might
> | > be hard for the core libraries committee to provide this guarantee. I
> | > suggest this requirement be dropped from the policy.
> | >
> | > Cheers,
> | > Simon
> | > _______________________________________________
> | > Glasgow-haskell-users mailing list
> | > [hidden email]
> | >
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
> | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
> | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
> | >
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | [hidden email]
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
> | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
> | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Warnings, -Wall, and versioning policy

Simon Peyton Jones
OK.  When this thread comes to a conclusion, can someone write it down; update the 3-release policy; and say what changes you want in GHC?

Thanks

Simon

| -----Original Message-----
| From: Gershom B [mailto:[hidden email]]
| Sent: 13 January 2016 18:18
| To: Simon Peyton Jones <[hidden email]>
| Cc: GHC users <[hidden email]>; [hidden email];
| Edward Kmett <[hidden email]>; Herbert Valerio Riedel <[hidden email]>; Simon
| Marlow <[hidden email]>
| Subject: Re: Warnings, -Wall, and versioning policy
|
| On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
| <[hidden email]> wrote:
|
| > An implication is that GHC is free to introduce new warnings X into -Wall.
| Indeed doing so would be good, because the warning X might later move into
| the default set.  Indeed for such warnings, adding a "PS: this warning will
| become the default in GHC 9.2" might be a useful way to signal the upcoming
| change.  Then you can use -Wall and look for any "PS" indicators.
|
| Yep. In general I think we don't know how _much_ noise a warning will
| create until it makes it into the wild, so just as with other new
| features its good to give them a bit of a "dry run" before deciding
| that they come "by default."
|
| > You don’t give a rationale for (2) but I think you intend that if someone
| wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to
| fall over.  Worth articulating the rationale.
|
| Yes, that's exactly the rationale. It doesn't help us short term, but
| longer term it should let users fiddle with warning flags more freely.
|
| I think the general issue with three releases is not whether or not
| GHC introduces warnings and at what pace, but that certain _types_ of
| warnings (in particular redundancies, be they constraints, imports,
| etc) will fire on entirely desirable code due to certain migration
| paths. Most of the tricks we developed for backwards-compatible
| migrations essentially depend on certain redundancies in code for a
| period. Those can't be removed without hurting backwards-compatibility
| of code, but their presence also induces warnings.
|
| So as a whole "warning freeness" and "backwards compatible migrations"
| become increasingly at odds with one another.
|
| A full refactor of our warning sets would probably help in this
| regard, so that the default advice could be "good code is -Wlint clean
| but not necessarily -Wpedantic clean". Or even "is clean under
| -Wpedantic -Wno-redundancies".
|
| --Gershom
|
| >
| > | -----Original Message-----
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | [hidden email]] On Behalf Of Gershom B
| > | Sent: 13 January 2016 02:20
| > | To: GHC users <[hidden email]>; [hidden email];
| > | Edward Kmett <[hidden email]>; Herbert Valerio Riedel <[hidden email]>;
| Simon
| > | Marlow <[hidden email]>
| > | Subject: Re: Warnings, -Wall, and versioning policy
| > |
| > | Hi Simon. I think you raise important issues here, although I believe
| you’re
| > | mistaken in one regard. Hackage rejects -Werror but I don’t think it
| rejects
| > | -Wall.
| > |
| > |  What I’d suggest is perhaps the following.
| > |
| > | 1) The libraries committee put forward -Wall cleanliness as an
| _aspirational
| > | goal_ rather than a final product, noting that the actual cleanliness
| might
| > | be with regards to `-Wall -Wno-foo -Wno-bar``.
| > |
| > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| > | than an _error_ on `-W` followed by an unrecognized string.
| > |
| > | 3) No warning flags be introduced into the _default_ set without at least
| a
| > | few releases in some other set such as `-Wall`.
| > |
| > | We may also want to try to maintain a “best practices” example cabal file
| > | that shows how one can build with additional warnings under a “dev” flag,
| and
| > | with fewer warnings otherwise — so that the noise inflicted on package
| devs
| > | under their builds doesn’t get inflicted on all end users, and even
| perhaps
| > | with different warning flags per ghc version flag.
| > |
| > | I think this will respect the concerns of people that like to use `-
| Wall`,
| > | want to have relatively warning clean code, and want to have some degree
| of
| > | backwards compatibility (which is not an unreasonable combination in my
| > | opinion).
| > |
| > | Some related
| > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and
| https://ghc.has
| > |
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2ft
| rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros
| oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47
| %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | Cheers,
| > | Gershom
| > |
| > |
| > | On January 12, 2016 at 11:18:57 AM, Simon Marlow ([hidden email])
| wrote:
| > | > Hi folks,
| > | >
| > | > We haven't described what guarantees GHC provides with respect to -Wall
| > | > behaviour across versions, and as a result there are some differing
| > | > expectations around this. It came up in this weeks' GHC meeting, so we
| > | > thought it would be a good idea to state the policy explicitly. Here it
| is:
| > | >
| > | > We guarantee that code that compiles with no warnings with -Wall
| > | > ("Wall-clean") and a particular GHC version, on a particular
| > | > platform, will be Wall-clean with future minor releases of the same
| > | > major GHC version on the same platform.
| > | >
| > | > (we plan to put this text in the User's Guide for future releases)
| > | >
| > | > There are no other guarantees. In particular:
| > | > - In a new major release, GHC may introduce new warnings into -Wall,
| > | > and/or change the meaning of existing warnings such that they trigger
| > | > (or not) under different conditions.
| > | > - GHC may generate different warnings on different platforms. (examples
| > | > of this are -fwarn-overflowed-literals and
| > | > -fwarn-unsupported-calling-conventions)
| > | >
| > | > Some rationale:
| > | > - We consider any change to the language that GHC accepts to be a
| > | > potentially code-breaking change, and subject to careful scrutiny. To
| > | > extend this to warnings would be a *lot* of work, and would make it
| > | > really difficult to introduce new warnings and improve the existing
| ones.
| > | > - Warnings can be based on analyses that can change in accuracy over
| > | > time. The -fwarn-unused-imports warning has changed a lot in what it
| > | > rejects, for example.
| > | > - We often introduce new warnings that naturally belong in -Wall. If
| > | > -Wall was required to be a fixed point, we would have to start
| > | > introducing new flags, and versioning, etc. and even keep the old
| > | > implementation of warnings when they change. It would get really messy.
| > | >
| > | > There are some consequences to this. -Wall -Werror is useful for
| > | > keeping your code warning-clean when developing, but shipping code with
| > | > these options turned on in the build system is asking for trouble when
| > | > building your code with different GHC versions and platforms. Keep
| > | > those options for development only. Hackage already rejects packages
| > | > that include -Wall for this reason.
| > | >
| > | > One reason we're raising this now is that it causes problems for the
| > | > 3-release policy
| > | >
| > |
| (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
| > | ll.org%2fwiki%2fLibraries%2f3-Release-
| > |
| Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
| > |
| 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
| > | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
| > | > requires that it be possible to write code that is Wall-clean with 3
| > | > major releases of GHC. GHC itself doesn't guarantee this, so it might
| > | > be hard for the core libraries committee to provide this guarantee. I
| > | > suggest this requirement be dropped from the policy.
| > | >
| > | > Cheers,
| > | > Simon
| > | > _______________________________________________
| > | > Glasgow-haskell-users mailing list
| > | > [hidden email]
| > | >
| > |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| > |
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
| > |
| 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
| > | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
| > | >
| > |
| > | _______________________________________________
| > | Glasgow-haskell-users mailing list
| > | [hidden email]
| > |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| > |
| users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
| > |
| 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
| > | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users