Re: [Xen-API] [PATCH] imported patch removing-warnings

[Jonathan Knowles <jonathan.knowles@xxxxxxxxxxxxx>]

(Apologies if this mail appears twice, the mail gateway was acting up)

On 10/11/10 15:30, Dave Scott wrote:
> My quick comments are: 1. a lot of warnings will be attributed to the
> "xen hg user" (have a look at "hg export 0")
Aha! The "xen hg user" should be held responsible for his actions. ;)

> 2. as a special case, it might be good to view fixing warnings as a
> task for newbies to help familiarise them with the codebase. I would
> agree with the notion that henceforth, new warnings should be treated
> as bugs and the creator should tidy them up.
One way that we could do this is to enable the "treat warnings as
errors switch". However, we can't do this yet, due to the rather
high number of existing warnings in the code. As such it's also
very difficult to spot the emergence of new warnings, as they tend
to get swamped out in all the noise.

A fresh run of "make" shows the following counts for each category:

        bad source file name                                2
        this argument will not be used by the function     10
        this expression should have type unit             105
        this match case is unused                           6
        this pattern-matching is not exhaustive            65
        this sub-pattern is unused                          3
        this statement never returns                        2
        unused variable                                   131

I'd be in favour of (some variant of) Rok's idea:

  * organise a concerted drive to get rid of all warnings, and then
  * permanently enable the "treat warnings as errors" compiler flag.

If we did decide to do this, then two questions spring to mind:

  1. As a team, how can we quickly and efficiently remove all the
         warnings, without introducing more errors into the code base?

         As an example of the care that we'd need to take, we wouldn't
         want to simply remove all assignments to unused variables, as
         we'd need to make sure that we're not relying on side-effects
         from RHS-expressions.

  2. When should we do this?

Thoughts? :)
Jonathan


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api