[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Compiler Warnings



The current implementation of the Compiler Warnings buffer has problems.
Here are my main complaints:

	1.  It noticeably slows the compiler, and pages a lot.

	2.  Its contents are usually things which are not Compiler
	Warnings, rather, things like "Loading DLA; FOO QFASL
	into package USER".

	3.  Recently, it has been unreliable.  Often my warnings
	do not even get there.

	4.  I don't like the [Page]s all over the place; I can't print
	the buffer without using tons of paper.

Here is a proposal for a clean way to do this: The compiler maintains
its own strucuture which remembers compiler warnings on a variable, say
COMPILER-WARNINGS-HISTORY.  Its value is a list, whose elements are
(generic-pathname fcn-warning-1 fcn-warning-2 ...).  For functions which
don't seem to come from a file, the generic-pathname is NIL.  Each
fcn-warning is of the form (fcn-spec exp reason), where exp and reason
are the arguments to BARF.  fcn-specs which have no errors are not on
this list.  Note that only warnings which come through BARF will appear
in this.

COMPILER-WARNINGS-HISTORY is maintained by BARF, which puts all errors
on it itself.  Also, when a file is compiled, the entry for that file is
removed from COMPILER-WARNINGS-HISTORY, and similarly, when a function
is compiled (by itself) the entry for that function is removed from the
history.  The history is set to NIL at BEFORE-COLD.

The Compiler Warnings buffer would be flushed by default.  A new
function (PRINT-COMPILER-WARNINGS &optional for-file stream) would
provide a simple interface for viewing compiler warnings.  Meta-X
Compiler Warnings would setup a compiler warnings buffer and go to it,
and Meta-X Edit Compiler Warnings would setup the buffer and behave as
at present, but might more reliably use COMPILER-WARNINGS-HISTORY to do
its dirtywork.

This scheme would increase modularity by leaving the job of maintaining
compiler warnings to the compiler, and solve problems 1 through 3 above.
Since Edit Compiler Warnings will have to be gone over anyway, I don't
see how fixing number 4 will have too many problems.

Comments and opinions?