Common Lisp the Language, 2nd Edition

25.1.1. Compiler Diagnostics

X3J13 voted in June 1987 (COMPILER-WARNING-STREAM)   to specify that compile and compile-file may output warning messages; any such messages should go to the stream that is the value of *error-output*.

X3J13 voted in June 1989 (COMPILER-DIAGNOSTICS)   to specify the use of conditions to signal various erroneous situations during compilation. First, note that error and warning conditions may be signaled either by the compiler itself or by code being processed by the compiler (for example, arbitrary errors may occur during compile-time macro expansion or processing of eval-when forms). Considering only those conditions signaled by the compiler (as opposed to during compilation):

• Conditions of type error may be signaled by the compiler in situations where the compilation cannot proceed without intervention. Examples of such situations may include errors when opening a file or syntax errors.

• Conditions of type warning may be signaled by the compiler in situations where the standard explicitly states that a warning must, should, or may be signaled. They may also be signaled when the compiler can determine that a situation would result at runtime that would have undefined consequences or would cause an error to be signaled. Examples of such situations may include violations of type declarations, altering or rebinding a constant defined with defconstant, calls to built-in Lisp functions with too few or too many arguments or with malformed keyword argument lists, referring to a variable declared ignore, or unrecognized declaration specifiers.

• The compiler is permitted to signal diagnostics about matters of programming style as conditions of type style-warning, a subtype of warning. Although a style-warning condition may be signaled in these situations, no implementation is required to do so. However, if an implementation does choose to signal a condition, that condition will be of type style-warning and will be signaled by a call to the function warn. Examples of such situations may include redefinition of a function with an incompatible argument list, calls to functions (other than built-in functions) with too few or too many arguments or with malformed keyword argument lists, unreferenced local variables not declared ignore, or standard declaration specifiers that are ignored by the particular compiler in question.

Both compile and compile-file are permitted (but not required) to establish a handler for conditions of type error. Such a handler might, for example, issue a warning and restart compilation from some implementation-dependent point in order to let the compilation proceed without manual intervention.

The functions compile and compile-file each return three values. See the definitions of these functions for descriptions of the first value. The second value is nil if no compiler diagnostics were issued, and true otherwise. The third value is nil if no compiler diagnostics other than style warnings were issued; a non-nil value indicates that there were ``serious'' compiler diagnostics issued or that other conditions of type error or warning (but not style-warning) were signaled during compilation.