[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: BUG-LISPM at MIT-AI
- Subject: Compiler Warnings
- From: David L. Andre <DLA at MIT-AI>
- Date: Mon ,25 Jan 82 02:37:00 EDT
- Cc: DLA at MIT-AI
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
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
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?