4.4.1 The Parts of the Error Message

The compiler will produce this warning:

File: /usr/me/stuff.lisp

In: DEFUN FOO
  (ZOQ Y)
-> ROQ PLOQ + 
==>
  Y
Warning: Result is a SYMBOL, not a NUMBER.

In this example we see each of the six possible parts of a compiler error message:

File: /usr/me/stuff.lisp

This is 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 or top-level form responsible for the error. 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 enclosing defmumble, then the outermost form is used. If there are multiple defmumbles, then they are all printed from the out 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 error. Original source means that the form directly appeared in the original input to the compiler, i.e. in the lambda passed to compile or the top-level form read from the source file. In this example, the expansion of the zoq macro was responsible for the error.

-> ROQ PLOQ +

This is the ıprocessing path that the compiler used to produce the errorful code. 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, ploq and +. These calls resulted from the expansion of the zoq macro.

==> Y

This is the ıactual source responsible for the error. 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.

Warning: Result is a SYMBOL, not a NUMBER.

This is the explanation the problem. In this example, the problem is that y evaluates to a symbol, but is in a context where a number is required (the argument to +).

Note that each part of the error 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. This is like the ``macroexpands to'' notation used in Common Lisp: The Language.
• The explanation is prefixed with the error severity (see section 4.4.4), either Error:, Warning:, or Note:.

Each part of the error message is more specific than the preceding one. If consecutive error messages are for nearby locations, then the front part of the error 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: /usr/me/stuff.lisp

In: DEFUN FOO
  (ZOQ Y)
-> ROQ 
==>
  (PLOQ (+ Y 3))
Warning: Undefined function: PLOQ

==>
  (ROQ (PLOQ (+ Y 3)))
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.