@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?
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.
@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{(and (< 0 safety) (or (>= safety 2) (>= safety 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. It should
-be noted that it is relatively easy to corrupt the heap when weak type
-checks are used, and type-errors are introduced into the program.
+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{(and (< safety 2) (< safety speed))}
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
projects / sbcl.git / blobdiff