X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fmanual%2Fcompiler.texinfo;h=0c03d9874a29bf33bb2f3850ba3e9ddc386bdb0a;hb=f2db6743b1fadeea9e72cb583d857851c87efcd4;hp=a8aab4f2a45c39dc3bf25c4d3359aa25e20503c8;hpb=53f4147704fbe48c03dd73d7b6a9f92c0a066ed8;p=sbcl.git diff --git a/doc/manual/compiler.texinfo b/doc/manual/compiler.texinfo index a8aab4f..0c03d98 100644 --- a/doc/manual/compiler.texinfo +++ b/doc/manual/compiler.texinfo @@ -11,11 +11,12 @@ naive translation. Efficiency issues are sufficiently varied and 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 @@ -77,6 +78,15 @@ Cancels the effect of a previous @code{sb-ext:muffle-condition} 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 - @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 @@ -156,8 +156,8 @@ to the @code{sb-ext:compiler-note}, and is used for problems which are 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. @@ -393,7 +393,7 @@ This message is not saying ``there is a problem somewhere in this @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 @@ -456,11 +456,10 @@ one level. @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 @@ -493,21 +492,28 @@ involving the @code{satisfies} type specifier. @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 @@ -516,21 +522,28 @@ selectable via @code{optimize} declarations. @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 @@ -862,6 +875,7 @@ is to slow the program by causing cache misses or even swapping. @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 @@ -1019,8 +1033,8 @@ character position and gives up on the entire source file. @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 @@ -1091,3 +1105,20 @@ open-coded. Even when not open-coded, a call to a standard function 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}.