(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
| 
Home