separate that they have their own chapter, @ref{Efficiency}.
@menu
-* Diagnostic Messages::
+* Diagnostic Messages::
* Handling of Types::
* Compiler Policy::
* Compiler Errors::
* Open Coding and Inline Expansion::
+* Interpreter::
@end menu
@node Diagnostic Messages
declaration.
@end deffn
+Various details of @emph{how} the compiler messages are printed can be
+controlled via the alist
+@code{sb-ext:*compiler-print-variable-alist*}.
+
+@include var-sb-ext-star-compiler-print-variable-alist-star.texinfo
+
+For information about muffling warnings signaled outside of the
+compiler, see @ref{Customization Hooks for Users}.
+
@c <!-- FIXME: How much control over error messages is in SBCL?
@c _ How much should be? How much of this documentation should
@c _ we save or adapt?
@c _ which is useful when debugging macros.
@c _ \end{defvar}
@c _
-@c _ \begin{defvar}{}{error-print-length}
-@c _ \defvarx{error-print-level}
-@c _
-@c _ These variables are the print level and print length used in
-@c _ printing error messages. The default values are \code{5} and
-@c _ \code{3}. If null, the global values of \code{*print-level*} and
-@c _ \code{*print-length*} are used.
-@c _ \end{defvar}
-@c _
@c _ \begin{defmac}{extensions:}{define-source-context}{%
@c _ \args{\var{name} \var{lambda-list} \mstar{form}}}
@c _
@c _
@c _ -->
-
@node Diagnostic Severity
@comment node-name, next, previous, up
@subsection Diagnostic Severity
@cindex Severity of compiler messages
-@cindex compiler diagnostic severity
+@cindex Compiler Diagnostic Severity
@tindex error
@tindex warning
@tindex style-warning
too mild for the standard condition classes, typically hints about how
efficiency might be improved. The @code{sb-ext:code-deletion-note}, a
subtype of @code{compiler-note}, is signalled when the compiler
-deletes user-supplied code, usually after proving that the code in
-question is unreachable.
+deletes user-supplied code after proving that the code in question is
+unreachable.
Future work for SBCL includes expanding this hierarchy of types to
allow more fine-grained control over emission of diagnostic messages.
@node The Processing Path
@comment node-name, next, previous, up
@subsubsection The Processing Path
-@cindex Processing path
+@cindex Processing Path
@cindex Macroexpansion
@cindex Source-to-source transformation
@comment node-name, next, previous, up
@section Handling of Types
-The most unusual features of the SBCL compiler (which is very
-similar to the original CMUCL compiler, also known as @dfn{Python})
-is its unusually sophisticated understanding of the Common Lisp type
-system and its unusually conservative approach to the implementation
-of type declarations.
+One of the most important features of the SBCL compiler (similar to
+the original CMUCL compiler, also known as @dfn{Python}) is its fairly
+sophisticated understanding of the Common Lisp type system and its
+conservative approach to the implementation of type declarations.
These two features reward the use of type declarations throughout
development, even when high performance is not a concern. Also, as
@subsection Declarations as Assertions
@findex safety
-The SBCL compiler treats type declarations differently from most
-other Lisp compilers. Under default compilation policy the compiler
-doesn't blindly believe type declarations, but considers them
-assertions about the program that should be checked: all type
-declarations that have not been proven to always hold are asserted at
-runtime.
+The SBCL compiler treats type declarations differently from most other
+Lisp compilers. Under default compilation policy the compiler doesn't
+blindly believe type declarations, but considers them assertions about
+the program that should be checked: all type declarations that have
+not been proven to always hold are asserted at runtime.
@quotation
@emph{Remaining bugs in the compiler's handling of types unfortunately
provide some exceptions to this rule, see @ref{Implementation
-Limitations}).}
+Limitations}.}
@end quotation
-There are three type checking policies available in SBCL,
-selectable via @code{optimize} declarations.
+CLOS slot types form a notable exception. Types declared using the
+@code{:type} slot option in @code{defclass} are asserted if and only
+if the class was defined in @emph{safe code} and the slot access
+location is in @emph{safe code} as well. This laxness does not pose
+any internal consistency issues, as the CLOS slot types are not
+available for the type inferencer, nor do CLOS slot types provide any
+efficiency benefits.
+
+There are three type checking policies available in SBCL, selectable
+via @code{optimize} declarations.
@table @strong
@item Full Type Checks
All declarations are considered assertions to be checked at runtime,
-and all type checks are precise.
+and all type checks are precise. The default compilation policy
+provides full type checks.
-Used when @code{(>= safety (max speed space compilation-speed)}. The
-default compilation policy provides full type checks.
+Used when @code{(or (>= safety 2) (>= safety speed 1))}.
@item Weak Type Checks
-Any or all type declarations may be believed without runtime
-assertions, and assertions that are done may be imprecise.
+Declared types may be simplified into faster to check supertypes: for
+example, @code{(or (integer -17 -7) (integer 7 17))} is simplified
+into @code{(integer -17 17)}.
+
+@strong{Note}: it is relatively easy to corrupt the heap when weak
+type checks are used if the program contains type-errors.
-Used when @code{(> 0 safety (max speed space compilation-speed)}.
+Used when @code{(and (< safety 2) (< safety speed))}
@item No Type Checks
All declarations are believed without assertions. Also disables
argument count and array bounds checking.
+@strong{Note}: any type errors in code where type checks are not
+performed are liable to corrupt the heap.
+
Used when @code{(= safety 0)}.
@end table
Ordinarily, when the @code{speed} quality is high, the compiler emits
notes to notify the programmer about its inability to apply various
-optimizations.
-
-Compiler diagnostics (of any severity other than @code{error}:
-@pxref{Diagnostic Severity}) can be silenced by using the
-@code{sb-ext:muffle-conditions} declaration, specifying the type of
-condition that is to be muffled (using an associated
-@code{muffle-warning} restart).
-
-To muffle all compiler notes:
-
-@lisp
-(declaim (sb-ext:muffle-conditions sb-ext:compiler-note))
-@end lisp
-
-Compiler diagnostics can also be muffled in the lexical scope of a
-declaration, and also lexically unmuffled by the use of the
-sb-ext:unmuffle-conditions, for instance:
-
-@lisp
-(defun foo (x)
- (declare (optimize speed) (fixnum x))
- (declare (sb-ext:muffle-conditions sb-ext:compiler-note))
- (values (* x 5) ; no compiler note from this
- (locally
- (declare (sb-ext:unmuffle-conditions sb-ext:compiler-note))
- ;; this one gives a compiler note
- (* x -5))))
-@end lisp
+optimizations. For selective muffling of these notes @xref{Controlling
+Verbosity}.
The value of @code{space} mostly influences the compiler's decision
whether to inline operations, which tend to increase the size of
@c _ In addition to suppressing type checks, \code{0} also suppresses
@c _ argument count checking, unbound-symbol checking and array bounds
@c _ checks.
+@c _ ... and checking of tag existence in RETURN-FROM and GO.
@c _
@c _\item[\code{extensions:inhibit-warnings}] \cindex{inhibit-warnings
@c _ optimization quality}This is a CMU extension that determines how
@c _(end of section on compiler policy)
@c _-->
+@include fun-sb-ext-describe-compiler-policy.texinfo
+@include fun-sb-ext-restrict-compiler-policy.texinfo
+@include macro-common-lisp-with-compilation-unit.texinfo
+
@node Compiler Errors
@comment node-name, next, previous, up
@section Compiler Errors
@comment node-name, next, previous, up
@section Open Coding and Inline Expansion
@cindex Open-coding
-@cindex inline expansion
-@cindex static functions
+@cindex Inline expansion
+@cindex Static functions
Since Common Lisp forbids the redefinition of standard functions, the
compiler can have special knowledge of these standard functions
may be transformed into a different function call (as in the last
example) or compiled as @emph{static call}. Static function call uses
a more efficient calling convention that forbids redefinition.
+
+@node Interpreter
+@comment node-name, next, previous, up
+@section Interpreter
+@cindex Interpreter
+@vindex sb-ext:*evaluator-mode*
+
+By default SBCL implements @code{eval} by calling the native code
+compiler. SBCL also includes an interpreter for use in special cases
+where using the compiler is undesirable, for example due to compilation
+overhead. Unlike in some other Lisp implementations, in SBCL interpreted
+code is not safer or more debuggable than compiled code.
+
+Switching between the compiler and the interpreter is done using the
+special variable @code{sb-ext:*evaluator-mode*}. As of 0.9.17, valid
+values for @code{sb-ext:*evaluator-mode*} are @code{:compile} and
+@code{:interpret}.
projects / sbcl.git / blobdiff