| blob | df17921f2a22dfe80775f9f985739d8527afacd1 |
1 ;;;; the top level interfaces to the compiler, plus some other
2 ;;;; compiler-related stuff (e.g. CL:CALL-ARGUMENTS-LIMIT) which
3 ;;;; doesn't obviously belong anywhere else
5 ;;;; This software is part of the SBCL system. See the README file for
6 ;;;; more information.
7 ;;;;
8 ;;;; This software is derived from the CMU CL system, which was
9 ;;;; written at Carnegie Mellon University and released into the
10 ;;;; public domain. The software is in the public domain and is
11 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
12 ;;;; files for more information.
16 ;;; FIXME: Doesn't this belong somewhere else, like early-c.lisp?
35 ;;; Whether reference to a thing which cannot be defined causes a full
36 ;;; warning.
41 ;;; Set to NIL to disable loop analysis for register allocation.
44 ;;; Bind this to a stream to capture various internal debugging output.
47 ;;; The current block compilation state. These are initialized to the
48 ;;; :BLOCK-COMPILE and :ENTRY-POINTS arguments that COMPILE-FILE was
49 ;;; called with.
50 ;;;
51 ;;; *BLOCK-COMPILE-ARG* holds the original value of the :BLOCK-COMPILE
52 ;;; argument, which overrides any internal declarations.
59 ;;; When block compiling, used by PROCESS-FORM to accumulate top level
60 ;;; lambdas resulting from compiling subforms. (In reverse order.)
64 ;;; The current non-macroexpanded toplevel form as printed when
65 ;;; *compile-print* is true.
69 #!+sb-doc
72 #!+sb-doc
75 #!+sb-doc
76 "When this is true, the compiler prints to *STANDARD-OUTPUT* progress
77 information about the phases of compilation of each function. (This
81 #!+sb-doc
82 "The defaulted pathname of the file currently being compiled, or NIL if not
85 #!+sb-doc
86 "The TRUENAME of the file currently being compiled, or NIL if not
93 ;;; the SOURCE-INFO structure for the current compilation. This is
94 ;;; null globally to indicate that we aren't currently in any
95 ;;; identifiable compilation.
98 ;;; This is true if we are within a WITH-COMPILATION-UNIT form (which
99 ;;; normally causes nested uses to be no-ops).
102 ;;; Count of the number of compilation units dynamically enclosed by
103 ;;; the current active WITH-COMPILATION-UNIT that were unwound out of.
106 ;;; Mumble conditional on *COMPILE-PROGRESS*.
123 ;; Used during compilation to map code paths to the matching
124 ;; instrumentation conses.
126 ;; Used during compilation to keep track of with source paths have been
127 ;; instrumented in which blocks.
129 ;; Stores the code coverage instrumentation results. Keys are namestrings,
130 ;; the value is a list of (CONS PATH STATE), where STATE is NIL for
131 ;; a path that has not been visited, and T for one that has.
134 \f
135 ;;;; WITH-COMPILATION-UNIT and WITH-COMPILATION-VALUES
138 #!+sb-doc
139 "WITH-COMPILATION-UNIT ({Key Value}*) Form*
140 This form affects compilations that take place within its dynamic extent. It
141 is intended to be wrapped around the compilation of all files in the same
142 system. These keywords are defined:
144 :OVERRIDE Boolean-Form
145 One of the effects of this form is to delay undefined warnings
146 until the end of the form, instead of giving them at the end of each
147 compilation. If OVERRIDE is NIL (the default), then the outermost
148 WITH-COMPILATION-UNIT form grabs the undefined warnings. Specifying
149 OVERRIDE true causes that form to grab any enclosed warnings, even if
150 it is enclosed by another WITH-COMPILATION-UNIT.
152 :SOURCE-PLIST Plist-Form
153 Attaches the value returned by the Plist-Form to internal debug-source
154 information of functions compiled in within the dynamic contour.
155 Primarily for use by development environments, in order to eg. associate
156 function definitions with editor-buffers. Can be accessed as
157 SB-INTROSPECT:DEFINITION-SOURCE-PLIST. If multiple, nested
158 WITH-COMPILATION-UNITs provide :SOURCE-PLISTs, they are appended
159 togather, innermost left. If Unaffected by :OVERRIDE."
169 ;; Inside another WITH-COMPILATION-UNIT, a WITH-COMPILATION-UNIT is
170 ;; ordinarily (unless OVERRIDE) basically a no-op.
194 ;;; Is NAME something that no conforming program can rely on
195 ;;; defining?
198 (:function
201 (:type
208 ;;; This is to be called at the end of a compilation unit. It signals
209 ;;; any residual warnings about unknown stuff, then prints the total
210 ;;; error counts. ABORT-P should be true when the compilation unit was
211 ;;; aborted by throwing out. ABORT-COUNT is the number of dynamically
212 ;;; enclosed nested compilation units that were aborted.
239 #+sb-xc-host nil
241 (:function
245 "~@<There is no function named ~S. References to ~S ~
246 in some contexts (like starts of blocks) have ~
247 special meaning, but here it would have to be a ~
248 function, and that shouldn't be right.~:@>" name
249 name))
252 "~@<The function ~S is undefined, and its name is ~
253 reserved by ANSI CL so that even if it were ~
254 defined later, the code doing so would not be ~
256 (:type
259 "~@<Undefined type ~S. The name starts with ~S: ~
260 probably use of a quoted type name in a context ~
261 where the name is not evaluated.~:@>"
264 "~@<Undefined type ~S. Note that name ~S is ~
265 reserved by ANSI CL, so code defining a type with ~
266 that name would not be portable.~:@>" name
267 name))))
276 "~W more use~:P of undefined ~(~A~) ~S"
277 more kind name)
279 "~W more use~:P of undefined ~(~A~) ~S"
280 more kind name))))))))))
290 abort-p)
294 "~& Undefined ~(~A~)~p:~
295 ~% ~{~<~% ~1:;~S~>~^ ~}"
298 ~[~:;~:*~& caught ~W ERROR condition~:P~]~
299 ~[~:;~:*~& caught ~W WARNING condition~:P~]~
300 ~[~:;~:*~& caught ~W STYLE-WARNING condition~:P~]~
301 ~[~:;~:*~& printed ~W note~:P~]"
310 ;;; Evaluate BODY, then return (VALUES BODY-VALUE WARNINGS-P
311 ;;; FAILURE-P), where BODY-VALUE is the first value of the body, and
312 ;;; WARNINGS-P and FAILURE-P are as in CL:COMPILE or CL:COMPILE-FILE.
313 ;;; This also wraps up WITH-IR1-NAMESPACE functionality.
321 \f
322 ;;;; component compilation
325 #!+sb-doc
326 "The upper limit on the number of times that we will consecutively do IR1
327 optimization that doesn't introduce any new code. A finite limit is
333 ;;; Repeatedly optimize COMPONENT until no further optimizations can
334 ;;; be found or we hit our iteration limit. When we hit the limit, we
335 ;;; clear the component and block REOPTIMIZE flags to discourage the
336 ;;; next optimization attempt from pounding on the same code.
380 ;;; KLUDGE: This was bumped from 5 to 10 in a DTC patch ported by MNA
381 ;;; from CMU CL into sbcl-0.6.11.44, the same one which allowed IR1
382 ;;; transforms to be delayed. Either DTC or MNA or both didn't explain
383 ;;; why, and I don't know what the rationale was. -- WHN 2001-04-28
384 ;;;
385 ;;; FIXME: It would be good to document why it's important to have a
386 ;;; large value here, and what the drawbacks of an excessively large
387 ;;; value are; and it might also be good to make it depend on
388 ;;; optimization policy.
394 ;;; Iterate doing FIND-DFO until no new dead code is discovered.
407 ;;; Do all the IR1 phases for a non-top-level component.
412 ;make this 0.
435 ;; We delay the generation of type checks until
436 ;; the type constraints have had time to
437 ;; propagate, else the compiler can confuse itself.
455 #!+inline-constants
457 #!+inline-constants
459 #!+inline-constants
473 ;; Assign BLOCK-NUMBER for any cleanup blocks introduced by
474 ;; stack analysis. There shouldn't be any unreachable code after
475 ;; control, so this won't delete anything.
525 #-sb-xc-host
537 code-length
538 trace-table
539 fixup-notes
545 code-length
546 trace-table
547 fixup-notes
551 ;; We're done, so don't bother keeping anything around.
556 ;;; Delete components with no external entry points before we try to
557 ;;; generate code. Unreachable closures can cause IR2 conversion to
558 ;;; puke on itself, since it is the reference to the closure which
559 ;;; normally causes the components to be combined.
566 (:external
574 ;; miscellaneous sanity checks
575 ;;
576 ;; FIXME: These are basically pretty wimpy compared to the checks done
577 ;; by the old CHECK-IR1-CONSISTENCY code. It would be really nice to
578 ;; make those internal consistency checks work again and use them.
583 ;; sanity check to prevent weirdness from propagating insidiously as
584 ;; far from its root cause as it did in bug 138: Make sure that
585 ;; thing-to-COMPONENT links are consistent.
591 ;; Record xref information before optimization. This way the
592 ;; stored xref data reflects the real source as closely as
593 ;; possible.
603 #|
615 |#
617 ;; FIXME: What is MAYBE-MUMBLE for? Do we need it any more?
631 \f
632 ;;;; clearing global data structures
633 ;;;;
634 ;;;; FIXME: Is it possible to get rid of this stuff, getting rid of
635 ;;;; global data structures entirely when possible and consing up the
636 ;;;; others from scratch instead of clearing and reusing them?
638 ;;; Clear the INFO in constants in the *FREE-VARS*, etc. In
639 ;;; addition to allowing stuff to be reclaimed, this is required for
640 ;;; correct assignment of constant offsets, since we need to assign a
641 ;;; new offset for each component. We don't clear the FUNCTIONAL-INFO
642 ;;; slots, since they are used to keep track of functions across
643 ;;; component boundaries.
656 ;;; Blow away the REFS for all global variables, and let COMPONENT
657 ;;; be recycled.
669 x))
677 ;;; Clear global variables used by the compiler.
678 ;;;
679 ;;; FIXME: It seems kinda nasty and unmaintainable to have to do this,
680 ;;; and it adds overhead even when people aren't using the compiler.
681 ;;; Perhaps we could make these global vars unbound except when
682 ;;; actually in use, so that this function could go away.
685 ;; Clear global tables.
691 ;; Clear debug counters and tables.
707 ;; (Note: The CMU CL code used to set CL::*GENSYM-COUNTER* to zero here.
708 ;; Superficially, this seemed harmful -- the user could reasonably be
709 ;; surprised if *GENSYM-COUNTER* turned back to zero when something was
710 ;; compiled. A closer inspection showed that this actually turned out to be
711 ;; harmless in practice, because CLEAR-STUFF was only called from within
712 ;; forms which bound CL::*GENSYM-COUNTER* to zero. However, this means that
713 ;; even though zeroing CL::*GENSYM-COUNTER* here turned out to be harmless in
714 ;; practice, it was also useless in practice. So we don't do it any more.)
717 \f
718 ;;;; trace output
720 ;;; Print out some useful info about COMPONENT to STREAM.
741 \f
742 ;;;; file reading
743 ;;;;
744 ;;;; When reading from a file, we have to keep track of some source
745 ;;;; information. We also exploit our ability to back up for printing
746 ;;;; the error context and for recovering from errors.
747 ;;;;
748 ;;;; The interface we provide to this stuff is the stream-oid
749 ;;;; SOURCE-INFO structure. The bookkeeping is done as a side effect
750 ;;;; of getting the next source form.
752 ;;; A FILE-INFO structure holds all the source information for a
753 ;;; given file.
756 #-no-ansi-print-object
760 ;; If a file, the truename of the corresponding source file. If from
761 ;; a Lisp form, :LISP. If from a stream, :STREAM.
763 ;; the external format that we'll call OPEN with, if NAME is a file.
765 ;; the defaulted, but not necessarily absolute file name (i.e. prior
766 ;; to TRUENAME call.) Null if not a file. This is used to set
767 ;; *COMPILE-FILE-PATHNAME*, and if absolute, is dumped in the
768 ;; debug-info.
770 ;; the file's write date (if relevant)
772 ;; the source path root number of the first form in this file (i.e.
773 ;; the total number of forms converted previously in this
774 ;; compilation)
776 ;; parallel vectors containing the forms read out of the file and
777 ;; the file positions that reading of each form started at (i.e. the
778 ;; end of the previous form)
782 ;;; The SOURCE-INFO structure provides a handle on all the source
783 ;;; information for an entire compilation.
785 #-no-ansi-print-object
789 ;; the UT that compilation started at
791 ;; the IRT that compilation started at
793 ;; the FILE-INFO structure for this compilation
795 ;; the stream that we are using to read the FILE-INFO, or NIL if
796 ;; no stream has been opened yet
798 ;; if the current compilation is recursive (e.g., due to EVAL-WHEN
799 ;; processing at compile-time), the invoking compilation's
800 ;; source-info.
803 ;;; Given a pathname, return a SOURCE-INFO structure.
808 :external-format external-format
811 ;;; Return a SOURCE-INFO to describe the incremental compilation of FORM.
819 ;;; Walk up the SOURCE-INFO list until we either reach a SOURCE-INFO
820 ;;; with no parent (e.g., from a REPL evaluation) or until we reach a
821 ;;; SOURCE-INFO whose FILE-INFO denotes a file.
829 finfo))))
831 ;;; Return a form read from STREAM; or for EOF use the trick,
832 ;;; popularized by Kent Pitman, of returning STREAM itself. If an
833 ;;; error happens, then convert it to standard abort-the-compilation
834 ;;; error condition (possibly recording some extra location
835 ;;; information).
841 :condition condition
842 ;; We don't need to supply :POSITION here because
843 ;; READER-ERRORs already know their position in the file.
844 ))
845 ;; ANSI, in its wisdom, says that READ should return END-OF-FILE
846 ;; (and that this is not a READER-ERROR) when it encounters end of
847 ;; file in the middle of something it's trying to read.
850 :condition condition
851 ;; We need to supply :POSITION here because the END-OF-FILE
852 ;; condition doesn't carry the position that the user
853 ;; probably cares about, where the failed READ began.
856 ;;; If STREAM is present, return it, otherwise open a stream to the
857 ;;; current file. There must be a current file.
858 ;;;
859 ;;; FIXME: This is probably an unnecessarily roundabout way to do
860 ;;; things now that we process a single file in COMPILE-FILE (unlike
861 ;;; the old CMU CL code, which accepted multiple files). Also, the old
862 ;;; comment said
863 ;;; When we open a new file, we also reset *PACKAGE* and policy.
864 ;;; This gives the effect of rebinding around each file.
865 ;;; which doesn't seem to be true now. Check to make sure that if
866 ;;; such rebinding is necessary, it's still done somewhere.
879 ;;; Close the stream in INFO if it is open.
887 ;;; Loop over FORMS retrieved from INFO. Used by COMPILE-FILE and
888 ;;; LOAD when loading from a FILE-STREAM associated with a source
889 ;;; file.
905 file-info))))
908 file-info))
912 ;;; Read and compile the source file.
919 ;;; Return the INDEX'th source form read from INFO and the position
920 ;;; where it was read.
926 \f
927 ;;;; processing of top level forms
929 ;;; This is called by top level form processing when we are ready to
930 ;;; actually compile something. If *BLOCK-COMPILE* is T, then we still
931 ;;; convert the form, but delay compilation, pushing the result on
932 ;;; *TOPLEVEL-LAMBDAS* instead.
936 ;; Don't bother to compile simple objects that just sit there.
949 nil)))))
951 ;;; Macroexpand FORM in the current environment with an error handler.
952 ;;; We only expand one level, so that we retain all the intervening
953 ;;; forms in the source path.
961 condition))))
963 ;;; Process a PROGN-like portion of a top level form. FORMS is a list of
964 ;;; the forms, and PATH is the source path of the FORM they came out of.
965 ;;; COMPILE-TIME-TOO is as in ANSI "3.2.3.1 Processing of Top Level Forms".
971 ;;; Process a top level use of LOCALLY, or anything else (e.g.
972 ;;; MACROLET) at top level which has declarations and ordinary forms.
973 ;;; We parse declarations and then recursively process the body.
979 ;; FIXME: VALUES declaration
980 ;;
981 ;; Binding *POLICY* is pretty much of a hack, since it
982 ;; causes LOCALLY to "capture" enclosed proclamations. It
983 ;; is necessary because CONVERT-AND-MAYBE-COMPILE uses the
984 ;; value of *POLICY* as the policy. The need for this hack
985 ;; is due to the quirk that there is no way to represent in
986 ;; a POLICY that an optimize quality came from the default.
987 ;;
988 ;; FIXME: Ideally, something should be done so that DECLAIM
989 ;; inside LOCALLY works OK. Failing that, at least we could
990 ;; issue a warning instead of silently screwing up.
992 ;; This is probably also a hack
994 ;; ditto
998 ;;; Parse an EVAL-WHEN situations list, returning three flags,
999 ;;; (VALUES COMPILE-TOPLEVEL LOAD-TOPLEVEL EXECUTE), indicating
1000 ;;; the types of situations present in the list.
1004 '(:compile-toplevel
1005 compile
1006 :load-toplevel
1007 load
1008 :execute
1009 eval)))
1014 deprecated-names)))
1016 situations)
1021 ;;; utilities for extracting COMPONENTs of FUNCTIONALs
1032 result))))
1036 result))))
1039 &key
1040 name
1042 ;; I'd thought NIL should
1043 ;; work, but it doesn't.
1044 ;; -- WHN 2001-09-20
1055 lambda-expression
1057 ;; Convert the XEP using the policy of the real
1058 ;; function. Otherwise the wrong policy will be used for
1059 ;; deciding whether to type-check the parameters of the
1060 ;; real function (via CONVERT-CALL / PROPAGATE-TO-ARGS).
1061 ;; -- JES, 2007-02-27
1065 :source-name source-name
1074 fun)))
1076 ;;; Compile LAMBDA-EXPRESSION into *COMPILE-OBJECT*, returning a
1077 ;;; description of the result.
1078 ;;; * If *COMPILE-OBJECT* is a CORE-OBJECT, then write the function
1079 ;;; into core and return the compiled FUNCTION value.
1080 ;;; * If *COMPILE-OBJECT* is a fasl file, then write the function
1081 ;;; into the fasl file and return a dump handle.
1082 ;;;
1083 ;;; If NAME is provided, then we try to use it as the name of the
1084 ;;; function for debugging/diagnostic information.
1087 &key
1088 name
1090 ;; This magical idiom seems to be the appropriate
1091 ;; path for compiling standalone LAMBDAs, judging
1092 ;; from the CMU CL code and experiment, so it's a
1093 ;; nice default for things where we don't have a
1094 ;; real source path (as in e.g. inside CL:COMPILE).
1104 :name name
1107 ;; FIXME: The compile-it code from here on is sort of a
1108 ;; twisted version of the code in COMPILE-TOPLEVEL. It'd be
1109 ;; better to find a way to share the code there; or
1110 ;; alternatively, to use this code to replace the code there.
1111 ;; (The second alternative might be pretty easy if we used
1112 ;; the :LOCALL-ONLY option to IR1-FOR-LAMBDA. Then maybe the
1113 ;; whole FUNCTIONAL-KIND=:TOPLEVEL case could go away..)
1131 result
1132 ;; KLUDGE: This code duplicates some other code in this
1133 ;; file. In the great reorganzation, the flow of program
1134 ;; logic changed from the original CMUCL model, and that
1135 ;; path (as of sbcl-0.7.5 in SUB-COMPILE-FILE) was no
1136 ;; longer followed for CORE-OBJECTS, leading to BUG
1137 ;; 156. This place is transparently not the right one for
1138 ;; this code, but I don't have a clear enough overview of
1139 ;; the compiler to know how to rearrange it all so that
1140 ;; this operation fits in nicely, and it was blocking
1141 ;; reimplementation of (DECLAIM (INLINE FOO)) (MACROLET
1142 ;; ((..)) (DEFUN FOO ...))
1143 ;;
1144 ;; FIXME: This KLUDGE doesn't solve all the problem in an
1145 ;; ideal way, as (1) definitions typed in at the REPL
1146 ;; without an INLINE declaration will give a NULL
1147 ;; FUNCTION-LAMBDA-EXPRESSION (allowable, but not ideal)
1148 ;; and (2) INLINE declarations will yield a
1149 ;; FUNCTION-LAMBDA-EXPRESSION headed by
1150 ;; SB-C:LAMBDA-WITH-LEXENV, even for null LEXENV. -- CSR,
1151 ;; 2002-07-02
1152 ;;
1153 ;; (2) is probably fairly easy to fix -- it is, after all,
1154 ;; a matter of list manipulation (or possibly of teaching
1155 ;; CL:FUNCTION about SB-C:LAMBDA-WITH-LEXENV). (1) is
1156 ;; significantly harder, as the association between
1157 ;; function object and source is a tricky one.
1158 ;;
1159 ;; FUNCTION-LAMBDA-EXPRESSION "works" (i.e. returns a
1160 ;; non-NULL list) when the function in question has been
1161 ;; compiled by (COMPILE <x> '(LAMBDA ...)); it does not
1162 ;; work when it has been compiled as part of the top-level
1163 ;; EVAL strategy of compiling everything inside (LAMBDA ()
1164 ;; ...). -- CSR, 2002-11-02
1176 (%compile lambda-expression
1178 :name name
1192 form)
1201 form)
1205 ;;; Handle the evaluation the a :COMPILE-TOPLEVEL body during
1206 ;;; compilation. Normally just evaluate in the appropriate
1207 ;;; environment, but also compile if outputting a CFASL.
1214 ;;; Process a top level FORM with the specified source PATH.
1215 ;;; * If this is a magic top level form, then do stuff.
1216 ;;; * If this is a macro, then expand it.
1217 ;;; * Otherwise, just compile it.
1218 ;;;
1219 ;;; COMPILE-TIME-TOO is as defined in ANSI
1220 ;;; "3.2.3.1 Processing of Top Level Forms".
1231 path)
1236 ;; When we're cross-compiling, consider: what should we
1237 ;; do when we hit e.g.
1238 ;; (EVAL-WHEN (:COMPILE-TOPLEVEL)
1239 ;; (DEFUN FOO (X) (+ 7 X)))?
1240 ;; DEFUN has a macro definition in the cross-compiler,
1241 ;; and a different macro definition in the target
1242 ;; compiler. The only sensible thing is to use the
1243 ;; target compiler's macro definition, since the
1244 ;; cross-compiler's macro is in general into target
1245 ;; functions which can't meaningfully be executed at
1246 ;; cross-compilation time. So make sure we do the EVAL
1247 ;; here, before we macroexpand.
1248 ;;
1249 ;; Then things get even dicier with something like
1250 ;; (DEFCONSTANT-EQX SB!XC:LAMBDA-LIST-KEYWORDS ..)
1251 ;; where we have to make sure that we don't uncross
1252 ;; the SB!XC: prefix before we do EVAL, because otherwise
1253 ;; we'd be trying to redefine the cross-compilation host's
1254 ;; constants.
1255 ;;
1256 ;; (Isn't it fun to cross-compile Common Lisp?:-)
1257 #+sb-xc-host
1262 ;; like SB!XC:DEFCONSTANT and SB!XC:DEFTYPE
1263 ;; should be equivalent to their CL: counterparts
1264 ;; when being compiled as target code. We leave
1265 ;; the rest of the form uncrossed because macros
1266 ;; might yet expand into EVAL-WHEN stuff, and
1267 ;; things inside EVAL-WHEN can't be uncrossed
1268 ;; until after we've EVALed them in the
1269 ;; cross-compilation host.)
1273 slightly-uncrossed)))
1275 ;; (Now that we're no longer processing toplevel
1276 ;; forms, and hence no longer need to worry about
1277 ;; EVAL-WHEN, we can uncross everything.)
1279 ;; (We have to demote COMPILE-TIME-TOO to NIL
1280 ;; here, no matter what it was before, since
1281 ;; otherwise we'd tend to EVAL subforms more than
1282 ;; once, because of WHEN COMPILE-TIME-TOO form
1283 ;; above.)
1285 ;; When we're not cross-compiling, we only need to
1286 ;; macroexpand once, so we can follow the 1-thru-6
1287 ;; sequence of steps in ANSI's "3.2.3.1 Processing of
1288 ;; Top Level Forms".
1289 #-sb-xc-host
1297 path
1298 compile-time-too)))))))
1300 #+sb-xc-host
1301 ;; (There are no xc EVAL-WHEN issues in the ATOM case until
1302 ;; (1) SBCL gets smart enough to handle global
1303 ;; DEFINE-SYMBOL-MACRO or SYMBOL-MACROLET and (2) SBCL
1304 ;; implementors start using symbol macros in a way which
1305 ;; interacts with SB-XC/CL distinction.)
1307 #-sb-xc-host
1313 form))))
1315 ;; In the cross-compiler, top level COLD-FSET arranges
1316 ;; for static linking at cold init time.
1317 #+sb-xc-host
1323 lambda-expression
1324 path)))
1330 ;; CT, LT, and E here are as in Figure 3-7 of ANSI
1331 ;; "3.2.3.1 Processing of Top Level Forms".
1336 e))))
1338 body path new-compile-time-too))
1343 magic
1348 path
1349 compile-time-too))
1353 magic
1357 path
1358 compile-time-too
1368 \f
1369 ;;;; load time value support
1370 ;;;;
1371 ;;;; (See EMIT-MAKE-LOAD-FORM.)
1373 ;;; Return T if we are currently producing a fasl file and hence
1374 ;;; constants need to be dumped carefully.
1378 ;;; Compile FORM and arrange for it to be called at load-time. Return
1379 ;;; the dumper handle and our best guess at the type of the object.
1389 ;;; Compile the FORMS and arrange for them to be called (for effect,
1390 ;;; not value) at load time.
1395 ;;; Do the actual work of COMPILE-LOAD-TIME-VALUE or
1396 ;;; COMPILE-MAKE-LOAD-FORM-INIT-FORMS.
1402 lambda)))
1404 ;;; This is called by COMPILE-TOPLEVEL when it was passed T for
1405 ;;; LOAD-TIME-VALUE-P (which happens in COMPILE-LOAD-TIME-STUFF). We
1406 ;;; don't try to combine this component with anything else and frob
1407 ;;; the name. If not in a :TOPLEVEL component, then don't bother
1408 ;;; compiling, because it was merged with a run-time component.
1417 \f
1418 ;;;; COMPILE-FILE
1428 ;;; Smash LAMBDAS into a single component, compile it, and arrange for
1429 ;;; the resulting function to be called.
1439 ;;; Compile top level code and call the top level lambdas. We pick off
1440 ;;; top level lambdas in non-top-level components here, calling
1441 ;;; SUB-c-t-l-l on each subsequence of normal top level lambdas.
1450 lambdas
1451 ;; this used to read ":start start", but
1452 ;; start can be greater than len, which
1453 ;; is an error according to ANSI - CSR,
1454 ;; 2002-04-25
1456 len)))
1465 ;;; Compile LAMBDAS (a list of CLAMBDAs for top level forms) into the
1466 ;;; object file.
1467 ;;;
1468 ;;; LOAD-TIME-VALUE-P seems to control whether it's MAKE-LOAD-FORM and
1469 ;;; COMPILE-LOAD-TIME-VALUE stuff. -- WHN 20000201
1503 ;;; Actually compile any stuff that has been queued up for block
1504 ;;; compilation.
1524 lexenv))
1528 nil
1544 lexenv))
1554 ;;; Read all forms from INFO and compile them, with output to OBJECT.
1555 ;;; Return (VALUES ABORT-P WARNINGS-P FAILURE-P).
1583 ;; FIXME: Do we need this rebinding here? It's a literal
1584 ;; translation of the old CMU CL rebinding to
1585 ;; (OR *BACKEND-INFO-ENVIRONMENT* *INFO-ENVIRONMENT*),
1586 ;; and it's not obvious whether the rebinding to itself is
1587 ;; needed that SBCL doesn't need *BACKEND-INFO-ENVIRONMENT*.
1600 ;; Dump the code coverage records into the fasl.
1608 list))
1609 nil
1610 nil))
1618 nil)))
1619 ;; Some errors are sufficiently bewildering that we just fail
1620 ;; immediately, without trying to recover and compile more of
1621 ;; the input file.
1626 "~@<compilation aborted because of fatal error: ~2I~_~A~:>"
1627 condition))
1631 ;;; Return a pathname for the named file. The file must exist.
1640 new
1656 ;;; Print some junk at the beginning and end of compilation.
1664 file-info)
1666 :print-weekday nil
1673 won
1679 ;;; Open some files and call SUB-COMPILE-FILE. If something unwinds
1680 ;;; out of the compile, then abort the writing of the output file, so
1681 ;;; that we don't overwrite it with known garbage.
1684 &key
1686 ;; ANSI options
1688 ;; FIXME: ANSI doesn't seem to say anything about
1689 ;; *COMPILE-VERBOSE* and *COMPILE-PRINT* being rebound by this
1690 ;; function..
1695 ;; extensions
1699 #!+sb-doc
1700 "Compile INPUT-FILE, producing a corresponding fasl file and
1701 returning its filename.
1703 :PRINT
1704 If true, a message per non-macroexpanded top level form is printed
1705 to *STANDARD-OUTPUT*. Top level forms that whose subforms are
1706 processed as top level forms (eg. EVAL-WHEN, MACROLET, PROGN) receive
1707 no such message, but their subforms do.
1709 As an extension to ANSI, if :PRINT is :top-level-forms, a message
1710 per top level form after macroexpansion is printed to *STANDARD-OUTPUT*.
1711 For example, compiling an IN-PACKAGE form will result in a message about
1712 a top level SETQ in addition to the message about the IN-PACKAGE form'
1713 itself.
1715 Both forms of reporting obey the SB-EXT:*COMPILER-PRINT-VARIABLE-ALIST*.
1717 :BLOCK-COMPILE
1718 Though COMPILE-FILE accepts an additional :BLOCK-COMPILE
1719 argument, it is not currently supported. (non-standard)
1721 :TRACE-FILE
1722 If given, internal data structures are dumped to the specified
1723 file, or if a value of T is given, to a file of *.trace type
1724 derived from the input file name. (non-standard)
1726 :EMIT-CFASL
1727 (Experimental). If true, outputs the toplevel compile-time effects
1728 of this file into a separate .cfasl file."
1729 ;;; Block compilation is currently broken.
1730 #|
1731 "Also, as a workaround for vaguely-non-ANSI behavior, the
1732 :BLOCK-COMPILE argument is quasi-supported, to determine whether
1733 multiple functions are compiled together as a unit, resolving function
1734 references at compile time. NIL means that global function names are
1735 never resolved at compilation time. Currently NIL is the default
1737 of the ANSI spec allows this behavior under all circumstances, the
1738 compiler's runtime scales badly when it tries to do this for large
1739 files. If/when this performance problem is fixed, the block
1740 compilation default behavior will probably be made dependent on the
1741 SPEED and COMPILATION-SPEED optimization values, and the
1742 :BLOCK-COMPILE argument will probably become deprecated."
1743 |#
1776 default-trace-file-pathname
1778 default-trace-file-pathname))))
1812 ;; CLHS says that the first value is NIL if the "file could not
1813 ;; be created". We interpret this to mean "a valid fasl could not
1814 ;; be created" -- which can happen if the compilation is aborted
1815 ;; before the whole file has been processed, due to eg. a reader
1816 ;; error.
1818 ;; Hack around filesystem race condition...
1820 warnings-p
1821 failure-p)))
1822 \f
1823 ;;; a helper function for COMPILE-FILE-PATHNAME: the default for
1824 ;;; the OUTPUT-FILE argument
1825 ;;;
1826 ;;; ANSI: The defaults for the OUTPUT-FILE are taken from the pathname
1827 ;;; that results from merging the INPUT-FILE with the value of
1828 ;;; *DEFAULT-PATHNAME-DEFAULTS*, except that the type component should
1829 ;;; default to the appropriate implementation-defined default type for
1830 ;;; compiled files.
1834 retyped))
1836 ;;; KLUDGE: Part of the ANSI spec for this seems contradictory:
1837 ;;; If INPUT-FILE is a logical pathname and OUTPUT-FILE is unsupplied,
1838 ;;; the result is a logical pathname. If INPUT-FILE is a logical
1839 ;;; pathname, it is translated into a physical pathname as if by
1840 ;;; calling TRANSLATE-LOGICAL-PATHNAME.
1841 ;;; So I haven't really tried to make this precisely ANSI-compatible
1842 ;;; at the level of e.g. whether it returns logical pathname or a
1843 ;;; physical pathname. Patches to make it more correct are welcome.
1844 ;;; -- WHN 2000-12-09
1846 &key
1849 #!+sb-doc
1850 "Return a pathname describing what file COMPILE-FILE would write to given
1851 these arguments."
1855 \f
1856 ;;;; MAKE-LOAD-FORM stuff
1858 ;;; The entry point for MAKE-LOAD-FORM support. When IR1 conversion
1859 ;;; finds a constant structure, it invokes this to arrange for proper
1860 ;;; dumping. If it turns out that the constant has already been
1861 ;;; dumped, then we don't need to do anything.
1862 ;;;
1863 ;;; If the constant hasn't been dumped, then we check to see whether
1864 ;;; we are in the process of creating it. We detect this by
1865 ;;; maintaining the special *CONSTANTS-BEING-CREATED* as a list of all
1866 ;;; the constants we are in the process of creating. Actually, each
1867 ;;; entry is a list of the constant and any init forms that need to be
1868 ;;; processed on behalf of that constant.
1869 ;;;
1870 ;;; It's not necessarily an error for this to happen. If we are
1871 ;;; processing the init form for some object that showed up *after*
1872 ;;; the original reference to this constant, then we just need to
1873 ;;; defer the processing of that init form. To detect this, we
1874 ;;; maintain *CONSTANTS-CREATED-SINCE-LAST-INIT* as a list of the
1875 ;;; constants created since the last time we started processing an
1876 ;;; init form. If the constant passed to emit-make-load-form shows up
1877 ;;; in this list, then there is a circular chain through creation
1878 ;;; forms, which is an error.
1879 ;;;
1880 ;;; If there is some intervening init form, then we blow out of
1881 ;;; processing it by throwing to the tag PENDING-INIT. The value we
1882 ;;; throw is the entry from *CONSTANTS-BEING-CREATED*. This is so the
1883 ;;; offending init form can be tacked onto the init forms for the
1884 ;;; circular object.
1885 ;;;
1886 ;;; If the constant doesn't show up in *CONSTANTS-BEING-CREATED*, then
1887 ;;; we have to create it. We call MAKE-LOAD-FORM and check to see
1888 ;;; whether the creation form is the magic value
1889 ;;; :SB-JUST-DUMP-IT-NORMALLY. If it is, then we don't do anything. The
1890 ;;; dumper will eventually get its hands on the object and use the
1891 ;;; normal structure dumping noise on it.
1892 ;;;
1893 ;;; Otherwise, we bind *CONSTANTS-BEING-CREATED* and
1894 ;;; *CONSTANTS-CREATED-SINCE- LAST-INIT* and compile the creation form
1895 ;;; much the way LOAD-TIME-VALUE does. When this finishes, we tell the
1896 ;;; dumper to use that result instead whenever it sees this constant.
1897 ;;;
1898 ;;; Now we try to compile the init form. We bind
1899 ;;; *CONSTANTS-CREATED-SINCE-LAST-INIT* to NIL and compile the init
1900 ;;; form (and any init forms that were added because of circularity
1901 ;;; detection). If this works, great. If not, we add the init forms to
1902 ;;; the init forms for the object that caused the problems and let it
1903 ;;; deal with it.
1906 ;;; FIXME: Shouldn't these^ variables be unbound outside LET forms?
1910 ;; KLUDGE: This special hack is because I was too lazy
1911 ;; to rework DEF!STRUCT so that the MAKE-LOAD-FORM
1912 ;; function of LAYOUT returns nontrivial forms when
1913 ;; building the cross-compiler but :IGNORE-IT when
1914 ;; cross-compiling or running under the target Lisp. --
1915 ;; WHN 19990914
1924 ;; If the constant is a reference to a named constant, we can
1925 ;; just use SYMBOL-VALUE during LOAD.
1932 (:sb-just-dump-it-normally
1934 t)
1935 (:ignore-it
1936 nil)
1949 constant
1951 creation-form)
1953 nil)
1955 constant)))
1961 collect name into names
1962 collect form into forms
1964 nil)))
1969 \f
1970 ;;;; Host compile time definitions
1971 #+sb-xc-host
1976 #+sb-xc-host