Next: The Original and Actual Source, Up: Understanding Compiler Diagnostics

##### 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:

1. ``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.
2. ``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`.
3. ``(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.
4. ``--> 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.
5. ``==> (+ 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`.
6. ``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.