[Openmcl-devel] erroneous number of arguments in call to REPORT-FILE-COVERAGE and COVERAGE-STATS-HEAD
gb at clozure.com
Sat Sep 3 14:38:35 PDT 2011
This isn't interesting or unexpected (and no one wants to hear about it :)).
When you do (REBUILD-CCL), you're generally compiling version N of the sources
with an image built from a slightly older version of the sources. The newer
sources may contain (among other things) references to functions that aren't
defined (in either the running image or the compilation unit); functions'
signatures may change (your example includes a warning that a call doesn't
match "the current global definition" of the callee). If one really wanted
to suppress all warnings whenever some trivial change was made that might
be possible (e.g., by introducing FTYPE declarations at strategic points),
but this isn't generally a priority.
Once you've done REBUILD-CCL, the image that results will be based on current
sources. If you rebuild again (using that up-to-date image), then there
shouldn't be any warnings related to (small) differences between the sources
and the running image.
This is the trunk (the place where day-to-day development takes
place.) We want to be able to make changes to the code freely: it's
very hard to fix bugs, improve existing functionality, or add new
functionality without changing that code, and those changes may result
in compiler warnings. In this case, the person who made a change to
some internal functions related to code coverage don't have any real
impact on the system's ability to rebuild itself and that it was more
important to make that change than it was to worry about whether or
not those changes led to compiler warnings when an older image was
The particular case - changing a function and its callers to
accept/provide a different number of arguments - could be handled
differently: we might want to note that the callee's signature has
changed, we might want to see if we'd quietly missed some callers that
needed to change ... I don't think that we want to be totally quiet
about this (if anything, we may want to be more verbose about it.)
If you regularly rebuild your own code in an environment where (a slightly
earlier version of) that code is loaded, you'll likely run into some of
the same kinds of issues: changes that involve incompatibilities between
the running version and the new version might trigger compiler warnings.
You -might- want to go to great lengths to suppress those warnings, but
you might just as likely look at them, try to determine if any of them
was unexpected, and move on to more important things.
That scenario (where people do incremental development of a system while
that system is loaded) may not be as common as (I think) it once was.
It's pretty much what happens in REBUILD-CCL (and pretty much what has
to happen in that paradigm: we use a slightly-older-but-generally-compatible
version of CCL to generate the current version. Differences between those
versions can lead to compiler warnings, and it just isn't worth the effort
to suppress them.
We've probably missed on occasion, but we rarely check in changes that
cause these kinds of warnings where the warnings are significant. If
you don't want to take that on faith, you can rebuild with the new
image to convince yourself that the warnings likely had to do with
differences between versions.
(In the ARM Linux port of CCL, REBUILD-CCL always generates at least 4
warnings related to fairly obscure functions that aren't defined and that
we've been too lazy to define. Other than that, using an up-to-date image
to compile the sources it was built with shouldn't lead to warnings; using
a slightly older image to compile later sources sometimes does lead to warnings.)
For something that isn't interesting I managed to fill a dozen or so paragraphs
talking about it; I can sort of understand why someone who sees warnings when
building the trunk might think that that was noteworthy, but I hope that all
of this verbiage will dissuade them of that belief.
On Fri, 2 Sep 2011, Gabriel Dos Reis wrote:
> While rebuilding CCL (trunk) from a fresh check out, I
> noticed this warning that I thought you might want to hear about:
> ;Compiler warnings for "ccl:library;cover.lisp.newest" :
> ; In REPORT-COVERAGE: In the call to REPORT-FILE-COVERAGE with
> arguments (FRAME-FILE COVERAGE DIRECTORY HTML-NAME EXTERNAL-FORMAT),
> ; 5 arguments were provided, but at most 4 are accepted
> ; by the current global definition of REPORT-FILE-COVERAGE
> ; In REPORT-COVERAGE-TO-STREAMS: In the call to COVERAGE-STATS-HEAD
> with arguments (HTML-STREAM STATS-STREAM T),
> ; 3 arguments were provided, but at most 2 are accepted
> ; by the current global definition of COVERAGE-STATS-HEAD
> ;Compiling "/home/gdr/src/ccl.svn/library/leaks.lisp"...
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel