CLHS: Issue COMPILER-DIAGNOSTICS Writeup

Issue COMPILER-DIAGNOSTICS Writeup

Forum: Compiler

Issue: COMPILER-DIAGNOSTICS

References: CLtL p. 438-439, 62, 69, 160, 161

Condition System, Revision #18

S:>KMP>cl-conditions.text.34

Issue GC-MESSAGES

Issue RETURN-VALUES-UNSPECIFIED

Issue COMPILER-VERBOSITY

Issue CONDITION-RESTARTS

Category: CLARIFICATION, ENHANCEMENT

Edit History: V1, 15 Oct 1988, Sandra Loosemore

V2, 19 Oct 1988, Sandra Loosemore (minor fixes)

V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)

V4, 01 Nov 1988, Sandra Loosemore (fix typos)

V5, 15 Dec 1988, Dan L. Pierson (new condition types)

V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)

V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)

V8, 07 Jan 1989, Sandra Loosemore (expand discussion)

V9, 26 Jan 1989, Sandra Loosemore (simplify)

V10, 22 Mar 1989, Sandra Loosemore (error terminology)

V11, 11 Apr 1989, Kent Pitman (changes per X3J13)

V12, 21-Jun-89, Moon (changes to point 4 only: return a

status value from COMPILE also, make the status

value provide more detail)

V13, 22-Jun-89, Loosemore (fix one of the fixes)

V14, 04-Jul-89, Loosemore (amendments from June meeting)

Status: Passed V11 March 89

Passed V14 June 89

Problem Description:

It is unclear whether various diagnostics issued by the compiler are

supposed to be true errors and warnings, or merely messages.

In some implementations, COMPILE-FILE handles even serious error

situations (such as syntax errors) by printing a message and then

trying to recover and continue compiling the rest of the file, rather

than by signalling an error. While this user interface style is just

as acceptable as invoking the debugger, it means that a normal return

from COMPILE-FILE does not necessarily imply that the file was

successfully compiled.

Many compilers issue warnings about programming style issues (such as

binding a variable that is never used but not declared IGNORE).

Sometimes these messages obscure warnings about more serious problems,

and there should be some way to differentiate between the two. For

example, it should be possible to suppress the style warnings.

Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the

return value from COMPILE-FILE should be.

Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

(1) Introduce a new condition type, STYLE-WARNING, which is a subtype

of WARNING.

(2) Clarify that ERROR and WARNING conditions may be signalled within

COMPILE or COMPILE-FILE, including arbitrary errors which may

occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)

forms or macro expansion.

Considering only those conditions signalled -by- the compiler (as

opposed to -within- the compiler),

(a) Conditions of type ERROR may be signalled by the compiler in

situations where the compilation cannot proceed without

intervention.

Examples:

file open errors

syntax errors

(b) Conditions of type WARNING may be signalled by the compiler in

situations where the standard explicitly states that a warning must,

should, or may be signalled; and where the compiler can determine

that a situation with undefined consequences or that would cause

an error to be signalled would result at runtime.

Examples:

violation of type declarations

SETQ'ing or rebinding a constant defined with DEFCONSTANT

calls to built-in Lisp functions with wrong number of arguments

or malformed keyword argument lists

referencing a variable declared IGNORE

unrecognized declaration specifiers

programming style as conditions of type STYLE-WARNING. Although

STYLE-WARNINGs -may- be signalled 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 signalled by a call to

the function WARN.

Examples:

redefinition of function with different argument list

calls to function with wrong number of arguments

unreferenced local variables not declared IGNORE

declaration specifiers described in CLtL but ignored by

the compiler

(3) State that both COMPILE and COMPILE-FILE are permitted (but not

required) to establish a handler for ERROR. For example, they

might issue a warning, and restart compilation from some

implementation-dependent point in order to let the compilation

proceed without manual intervention.

(4) Specify that COMPILE and COMPILE-FILE return three values. The first

value from COMPILE is not changed by this proposal. The first value

from COMPILE-FILE is the truename of the output file, or NIL if the

file could not be created.

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 signalled during

compilation.

Rationale:

Introducing the STYLE-WARNING condition allows handlers to distinguish

between potentially serious problems and mere kibitzing on the part of

the compiler.

The second and third return values from COMPILE and COMPILE-FILE give

some indication of whether there were serious problems encountered in

compiling the file.

Current Practice:

No implementation behaves exactly as specified in this proposal.

In VaxLisp, COMPILE-FILE handles most compile-time errors without

invoking the debugger. (It gives up on that top-level form and moves on

to the next one.) Instead of signalling errors or warnings, it simply

prints them out as messages.

In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters

serious problems. COMPILE-FILE returns the pathname for the output file.

Symbolics Genera usually tries to keep compiling when it encounters errors;

so does Symbolics Cloe.

On the TI Explorer, the compiler tries to catch most errors and turn

them into warnings (except for errors on opening a file), but the user

can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants

to enter the debugger on an error signalled during reading, macro

expansion, or compile-time evaluation. The true name of the output

file is returned as the first value. A second value indicates whether

any errors or warnings were reported.

IIM Common Lisp's compiler handles errors using a resignalling mechanism

similar to what is described here.

Cost to implementors:

The cost to implementors is not trivial but not particularly high. This

proposal tries to allow implementations considerable freedom in what

kinds of conditions the compiler must detect and how they are handled,

while still allowing users some reasonably portable ways to deal with

compile-time errors.

Cost to users:

This is a compatible extension. This proposal may cause users to see

some small differences in the user interface to the compiler, but

implementations already vary quite widely in their approaches. Some

users will probably have to make some minor changes to their code.

Adding the STYLE-WARNING type may cause conflicts with programs

already using that name.

Benefits:

Users are given a way to detect and handle compilation errors, which

would simplify the implementation of portable code-maintenance

utilities. The behavior of the compiler in error situations is made

more uniform across implementations.

Discussion:

The issue of whether the compiler may print normal progress messages

is discussed in detail in a separate issue, COMPILER-VERBOSITY.

Explicit calls to ERROR don't really justify warnings to be signalled

at compile-time, but we assume implementors have some common sense

about when it's appropriate to do so.