4.1.3.1 The Parts of a Compiler Diagnostic
When processing this program, the compiler will produce this warning:
; file: /tmp/foo.lisp
; in: DEFUN FOO
; (ZOQ Y)
; --> ROQ PLOQ
; ==>
; (+ Y 3)
;
; caught WARNING:
; Asserted type NUMBER conflicts with derived type (VALUES SYMBOL &OPTIONAL).
In this example we see each of the six possible parts of a compiler
diagnostic:
- ‘file: /tmp/foo.lisp’ This is the name of the file that the
compiler read the relevant code from. The file name is displayed
because it may not be immediately obvious when there is an error
during compilation of a large system, especially when
with-compilation-unit
is used to delay undefined warnings.
- ‘in: DEFUN FOO’ This is the definition top level form responsible
for the diagnostic. It is obtained by taking the first two elements of
the enclosing form whose first element is a symbol beginning with
“‘def’”. If there is no such enclosing “‘def’” form,
then the outermost form is used. If there are multiple ‘def’
forms, then they are all printed from the outside in, separated by
‘=>’'s. In this example, the problem was in the
defun
for
foo
.
- ‘(ZOQ Y)’ This is the original source form responsible for
the diagnostic. Original source means that the form directly appeared
in the original input to the compiler, i.e. in the lambda passed to
compile
or in the top level form read from the source file. In
this example, the expansion of the zoq
macro was responsible
for the message.
- ‘--> ROQ PLOQ’ This is the processing path that the
compiler used to produce the code that caused the message to be
emitted. The processing path is a representation of the evaluated
forms enclosing the actual source that the compiler encountered when
processing the original source. The path is the first element of each
form, or the form itself if the form is not a list. These forms result
from the expansion of macros or source-to-source transformation done
by the compiler. In this example, the enclosing evaluated forms are
the calls to
roq
and ploq
. These calls resulted from the
expansion of the zoq
macro.
- ‘==> (+ Y 3)’ This is the actual source responsible for the
diagnostic. If the actual source appears in the explanation, then we
print the next enclosing evaluated form, instead of printing the
actual source twice. (This is the form that would otherwise have been
the last form of the processing path.) In this example, the problem is
with the evaluation of the reference to the variable
y
.
- ‘caught WARNING: Asserted type NUMBER conflicts with derived type
(VALUES SYMBOL &OPTIONAL).’ This is the explanation of the
problem. In this example, the problem is that, while the call to
+
requires that its arguments are all of type number
,
the compiler has derived that y
will evaluate to a
symbol
. Note that ‘(VALUES SYMBOL &OPTIONAL)’ expresses
that y
evaluates to precisely one value.
Note that each part of the message is distinctively marked:
- ‘file:’ and ‘in:’ mark the file and definition,
respectively.
- The original source is an indented form with no prefix.
- Each line of the processing path is prefixed with ‘-->’
- The actual source form is indented like the original source, but is
marked by a preceding ‘==>’ line.
- The explanation is prefixed with the diagnostic severity, which can be
‘caught ERROR:’, ‘caught WARNING:’, ‘caught
STYLE-WARNING:’, or ‘note:’.
Each part of the message is more specific than the preceding one. If
consecutive messages are for nearby locations, then the front part of
the messages would be the same. In this case, the compiler omits as
much of the second message as in common with the first. For example:
; file: /tmp/foo.lisp
; in: DEFUN FOO
; (ZOQ Y)
; --> ROQ
; ==>
; (PLOQ (+ Y 3))
;
; caught STYLE-WARNING:
; undefined function: PLOQ
; ==>
; (ROQ (PLOQ (+ Y 3)))
;
; caught STYLE-WARNING:
; undefined function: ROQ
In this example, the file, definition and original source are
identical for the two messages, so the compiler omits them in the
second message. If consecutive messages are entirely identical, then
the compiler prints only the first message, followed by: ‘[Last
message occurs repeats times]’ where repeats is the number
of times the message was given.
If the source was not from a file, then no file line is printed. If
the actual source is the same as the original source, then the
processing path and actual source will be omitted. If no forms
intervene between the original source and the actual source, then the
processing path will also be omitted.