Let's fix how warnings are specified

Let's fix how warnings are specified

[Mark H Weaver]

Hello all,

At present, compile-time warnings can only be enabled, not disabled, and
there is no way to enable all warnings.  This means that the set of
warnings has to be hard-coded into every build system.  This is terrible
because it means that every time we add a new warning type, users won't
benefit from it unless they update their Makefiles.

We need a way for users to ask for a reasonable default set of warnings
(which should be almost all of them), possibly with some warnings
explicitly enabled or disabled.  We should also have a way to enable all
warnings.

It would also be nice if this could be done in such a way that external
build systems can do this without breaking compatibility with Guile
2.0.[0-5].

I'm looking for ideas of how to adjust our 'compile' and 'guild compile'
interfaces to accomplish these objectives.

Here's a preliminary proposal:

* Add new pseudo-warning types 'all' and 'default'.
* For each specific warning type 'FOO', we add 'no-FOO'.
* These new pseudo-warning types would be honored by both
  'compile' and 'guild compile'.

What do you think?

    Mark

Re: Let's fix how warnings are specified

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Here's a preliminary proposal:
>
> * Add new pseudo-warning types 'all' and 'default'.

Yes, but only at the UI level–i.e., in ‘guild compile’, along with
‘help’.

At the programming level there are better ways to do this, namely
(map car %warning-types) and %auto-compilation-options.

> * For each specific warning type 'FOO', we add 'no-FOO'.

Ditto.

(Keep in mind that currently, #:opts (#:warnings ()) means literally
zero warnings, and #:opts (#:warnings (foo)) means “only warning foo”.)

WDYT?

Thanks,
Ludo’.

Re: Let's fix how warnings are specified

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Here's a preliminary proposal:
>>
>> * Add new pseudo-warning types 'all' and 'default'.
>
> Yes, but only at the UI level–i.e., in ‘guild compile’, along with
> ‘help’.

The fundamental problem with this strategy is that it requires a
centralized master list of warning types, which makes it very awkward
for users to add their own new warning types that can be explicitly
disabled.

I'd like users to be able to write this within a procedural macro:

  (if (warning-requested? 'my-new-warning #t)
      (my-new-warning-pass x))

The second argument to 'warning-requested?' specifies whether this new
warning is in the 'default' set of warnings.

I already have a patch set that implements this.  It is simple to
implement and convenient to use.  There is no comprehensive centralized
list of warnings.  'warning-requested?' is implemented like this:

  (define* (warning-requested? name
                               #:optional
                               (default? #t)
                               (spec (fluid-ref *requested-warnings-spec*)))
    (and (or (memq name spec)
             (memq 'all spec)
             (and default? (memq 'default spec)))
         (not (memq (symbol-append 'no- name) spec))))

The warning message includes the name of the warning type, so if the
user sees too many spurious warnings of that type, they can easily
disable it.

With your strategy, please consider what would be required for a library
author to export a macro that issues a new warning type that can be
disabled by the user.  The warning would not be shown unless users of
the library arranged to extend their centralized %warning-types,
%default-warning-types, %auto-compilation-options, and possibly their
own code that calls 'compile'.

Given all this hassle, it is likely that library writers will simply
issue warnings that cannot be disabled, or that must be disabled using a
non-standard mechanism.

> At the programming level there are better ways to do this, namely
> (map car %warning-types) and %auto-compilation-options.

Even for users, this is very awkward.  From a user's perspective, the
most common case (apart from using all defaults) is to _disable_ one or
more warnings, but to otherwise use the default set.

Following your suggestion, compiling something with the 'format' and
'bad-case-datum' warnings disabled (but otherwise using the default
warnings) looks something like this:

  (compile x #:opts `(#:warnings
                      ,(lset-difference
                        eq?
                        (or (and=> (memq #:warnings
                                         %auto-compilation-options)
                                   cadr)
                            '())
                        '(format bad-case-datum))))

With my proposal, it looks like this:

  (compile x #:opts '(#:warnings (default no-format no-bad-case-datum)))

Of course, with suitable helper functions, we could make it easier to
construct a desired set of warnings, but again, it still has the
fundamental problem that a centralized list of warnings inhibits users
from adding their own new warning types that can be disabled in the
standard way.

    Thanks,
      Mark

Re: Let's fix how warnings are specified

[Andy Wingo]

Hi,

FWIW, I'm fine with whatever you all agree upon in the end, though I am
sympathetic to Mark's concerns here.

One thing:

On Tue 14 Feb 2012 17:56, Mark H Weaver <mhw@netris.org> writes:

>   (compile x #:opts '(#:warnings (default no-format no-bad-case-datum)))

Let's pave this cowpath and add a #:warnings option to compile.  It
could default to #f.  If it's not #f, then we require it to be a list,
and append `(#:warnings ,warnings) to the #:opts.

IMO anyway :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: Let's fix how warnings are specified

[Ludovic Courtès]

Hello!

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Here's a preliminary proposal:
>>>
>>> * Add new pseudo-warning types 'all' and 'default'.
>>
>> Yes, but only at the UI level–i.e., in ‘guild compile’, along with
>> ‘help’.
>
> The fundamental problem with this strategy is that it requires a
> centralized master list of warning types, which makes it very awkward
> for users to add their own new warning types that can be explicitly
> disabled.

It can be centralized and user-extensible, can’t it?  For instance,
(system base message) could export ‘register-warning-type!’.

> I'd like users to be able to write this within a procedural macro:
>
>   (if (warning-requested? 'my-new-warning #t)
>       (my-new-warning-pass x))
>
> The second argument to 'warning-requested?' specifies whether this new
> warning is in the 'default' set of warnings.

Sounds good.

What about using <warning-type> objects instead of symbols?

Besides, message output ought to remain centralized, for various
reasons.  We don’t want users to use ‘format’ or ‘display’ to write
anything in free-form style anywhere.  ;-)

> Following your suggestion, compiling something with the 'format' and
> 'bad-case-datum' warnings disabled (but otherwise using the default
> warnings) looks something like this:
>
>   (compile x #:opts `(#:warnings
>                       ,(lset-difference
>                         eq?
>                         (or (and=> (memq #:warnings
>                                          %auto-compilation-options)
>                                    cadr)
>                             '())
>                         '(format bad-case-datum))))

Or:

  #:warnings (remove (cut memq <> '(format bad-case-datum))
                     %auto-compilation-options)

Yes, it’s more verbose than ‘no-format’, etc., but again: it’s a
/programming/ interface, so it’s also more expressive.

I find it important to distinguish between the programming interface and
the user interface, because the expectations are very different.  And
it’s similarly important to distinguish what belongs in each category.

To me, ‘compile’ is rather part of the programming interface, because
there’s nothing else to do the job.

Andy Wingo <wingo@pobox.com> skribis:

> Let's pave this cowpath and add a #:warnings option to compile.  It
> could default to #f.  If it's not #f, then we require it to be a list,
> and append `(#:warnings ,warnings) to the #:opts.

Yes, sounds good!

Thanks,
Ludo’.

Re: Let's fix how warnings are specified

[Andy Wingo]

Hi!

Mark, are you still interested in implementing this?  It would be very
nice :)

On Thu 16 Feb 2012 22:22, ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> Here's a preliminary proposal:
>>>>
>>>> * Add new pseudo-warning types 'all' and 'default'.
>>>
>>> Yes, but only at the UI level–i.e., in ‘guild compile’, along with
>>> ‘help’.
>>
>> The fundamental problem with this strategy is that it requires a
>> centralized master list of warning types, which makes it very awkward
>> for users to add their own new warning types that can be explicitly
>> disabled.
>
> It can be centralized and user-extensible, can’t it?  For instance,
> (system base message) could export ‘register-warning-type!’.

I agree with Ludo here -- for example in GCC, -Wall doesn't actually
enable all warnings, just more of them.  You need to be able to list the
set of enabled warning passes I think.  Dunno.

> Andy Wingo <wingo@pobox.com> skribis:
>
>> Let's pave this cowpath and add a #:warnings option to compile.  It
>> could default to #f.  If it's not #f, then we require it to be a list,
>> and append `(#:warnings ,warnings) to the #:opts.
>
> Yes, sounds good!

This would also be nice :)

Regards,

Andy
-- 
http://wingolog.org/