| blob | 41c49a175416c3358c9a402ae8dd5426df6a2b99 |
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?
36 ;;; Bind this to a stream to capture various internal debugging output.
39 ;;; The current block compilation state. These are initialized to the
40 ;;; :BLOCK-COMPILE and :ENTRY-POINTS arguments that COMPILE-FILE was
41 ;;; called with.
42 ;;;
43 ;;; *BLOCK-COMPILE-ARG* holds the original value of the :BLOCK-COMPILE
44 ;;; argument, which overrides any internal declarations.
51 ;;; When block compiling, used by PROCESS-FORM to accumulate top level
52 ;;; lambdas resulting from compiling subforms. (In reverse order.)
57 #!+sb-doc
60 #!+sb-doc
63 #!+sb-doc
64 "When this is true, the compiler prints to *ERROR-OUTPUT* progress
65 information about the phases of compilation of each function. (This
69 #!+sb-doc
70 "The defaulted pathname of the file currently being compiled, or NIL if not
73 #!+sb-doc
74 "The TRUENAME of the file currently being compiled, or NIL if not
81 ;;; the SOURCE-INFO structure for the current compilation. This is
82 ;;; null globally to indicate that we aren't currently in any
83 ;;; identifiable compilation.
86 ;;; This is true if we are within a WITH-COMPILATION-UNIT form (which
87 ;;; normally causes nested uses to be no-ops).
90 ;;; This lock is siezed in the same situation: the compiler is not
91 ;;; presently thread-safe
95 ;;; Count of the number of compilation units dynamically enclosed by
96 ;;; the current active WITH-COMPILATION-UNIT that were unwound out of.
99 ;;; Mumble conditional on *COMPILE-PROGRESS*.
110 \f
111 ;;;; WITH-COMPILATION-UNIT and WITH-COMPILATION-VALUES
114 #!+sb-doc
115 "WITH-COMPILATION-UNIT ({Key Value}*) Form*
116 This form affects compilations that take place within its dynamic extent. It
117 is intended to be wrapped around the compilation of all files in the same
118 system. These keywords are defined:
119 :OVERRIDE Boolean-Form
120 One of the effects of this form is to delay undefined warnings
121 until the end of the form, instead of giving them at the end of each
122 compilation. If OVERRIDE is NIL (the default), then the outermost
123 WITH-COMPILATION-UNIT form grabs the undefined warnings. Specifying
124 OVERRIDE true causes that form to grab any enclosed warnings, even if
125 it is enclosed by another WITH-COMPILATION-UNIT."
132 ;; Inside another WITH-COMPILATION-UNIT, a WITH-COMPILATION-UNIT is
133 ;; ordinarily (unless OVERRIDE) basically a no-op.
138 ;; FIXME: Now *COMPILER-FOO-COUNT* stuff is bound in more than
139 ;; one place. If we can get rid of the IR1 interpreter, this
140 ;; should be easier to clean up.
160 ;;; This is to be called at the end of a compilation unit. It signals
161 ;;; any residual warnings about unknown stuff, then prints the total
162 ;;; error counts. ABORT-P should be true when the compilation unit was
163 ;;; aborted by throwing out. ABORT-COUNT is the number of dynamically
164 ;;; enclosed nested compilation units that were aborted.
187 "~W more use~:P of undefined ~(~A~) ~S"
188 more kind name))))))
196 "~:[This ~(~A~) is~;These ~(~A~)s are~] undefined:~
197 ~% ~{~<~% ~1:;~S~>~^ ~}"
209 ~[~:;~:*~& caught ~W fatal ERROR condition~:P~]~
210 ~[~:;~:*~& caught ~W ERROR condition~:P~]~
211 ~[~:;~:*~& caught ~W WARNING condition~:P~]~
212 ~[~:;~:*~& caught ~W STYLE-WARNING condition~:P~]~
213 ~[~:;~:*~& printed ~W note~:P~]"
214 abort-p
222 ;;; Evaluate BODY, then return (VALUES BODY-VALUE WARNINGS-P
223 ;;; FAILURE-P), where BODY-VALUE is the first value of the body, and
224 ;;; WARNINGS-P and FAILURE-P are as in CL:COMPILE or CL:COMPILE-FILE.
225 ;;; This also wraps up WITH-IR1-NAMESPACE functionality.
233 \f
234 ;;;; component compilation
237 #!+sb-doc
238 "The upper limit on the number of times that we will consecutively do IR1
239 optimization that doesn't introduce any new code. A finite limit is
245 ;;; Repeatedly optimize COMPONENT until no further optimizations can
246 ;;; be found or we hit our iteration limit. When we hit the limit, we
247 ;;; clear the component and block REOPTIMIZE flags to discourage the
248 ;;; next optimization attempt from pounding on the same code.
288 ;;; KLUDGE: This was bumped from 5 to 10 in a DTC patch ported by MNA
289 ;;; from CMU CL into sbcl-0.6.11.44, the same one which allowed IR1
290 ;;; transforms to be delayed. Either DTC or MNA or both didn't explain
291 ;;; why, and I don't know what the rationale was. -- WHN 2001-04-28
292 ;;;
293 ;;; FIXME: It would be good to document why it's important to have a
294 ;;; large value here, and what the drawbacks of an excessively large
295 ;;; value are; and it might also be good to make it depend on
296 ;;; optimization policy.
302 ;;; Iterate doing FIND-DFO until no new dead code is discovered.
315 ;;; Do all the IR1 phases for a non-top-level component.
341 ;; We delay the generation of type checks until
342 ;; the type constraints have had time to
343 ;; propagate, else the compiler can confuse itself.
372 ;; Assign BLOCK-NUMBER for any cleanup blocks introduced by
373 ;; stack analysis. There shouldn't be any unreachable code after
374 ;; control, so this won't delete anything.
433 code-length
434 trace-table
435 fixups
441 code-length
442 trace-table
443 fixups
447 ;; We're done, so don't bother keeping anything around.
452 ;;; Delete components with no external entry points before we try to
453 ;;; generate code. Unreachable closures can cause IR2 conversion to
454 ;;; puke on itself, since it is the reference to the closure which
455 ;;; normally causes the components to be combined.
462 (:external
470 ;; miscellaneous sanity checks
471 ;;
472 ;; FIXME: These are basically pretty wimpy compared to the checks done
473 ;; by the old CHECK-IR1-CONSISTENCY code. It would be really nice to
474 ;; make those internal consistency checks work again and use them.
479 ;; sanity check to prevent weirdness from propagating insidiously as
480 ;; far from its root cause as it did in bug 138: Make sure that
481 ;; thing-to-COMPONENT links are consistent.
491 ;; FIXME: What is MAYBE-MUMBLE for? Do we need it any more?
508 \f
509 ;;;; clearing global data structures
510 ;;;;
511 ;;;; FIXME: Is it possible to get rid of this stuff, getting rid of
512 ;;;; global data structures entirely when possible and consing up the
513 ;;;; others from scratch instead of clearing and reusing them?
515 ;;; Clear the INFO in constants in the *FREE-VARS*, etc. In
516 ;;; addition to allowing stuff to be reclaimed, this is required for
517 ;;; correct assignment of constant offsets, since we need to assign a
518 ;;; new offset for each component. We don't clear the FUNCTIONAL-INFO
519 ;;; slots, since they are used to keep track of functions across
520 ;;; component boundaries.
533 ;;; Blow away the REFS for all global variables, and let COMPONENT
534 ;;; be recycled.
546 x))
554 ;;; Clear global variables used by the compiler.
555 ;;;
556 ;;; FIXME: It seems kinda nasty and unmaintainable to have to do this,
557 ;;; and it adds overhead even when people aren't using the compiler.
558 ;;; Perhaps we could make these global vars unbound except when
559 ;;; actually in use, so that this function could go away.
562 ;; Clear global tables.
568 ;; Clear debug counters and tables.
584 ;; Clear some PACK data structures (for GC purposes only).
590 ;; (Note: The CMU CL code used to set CL::*GENSYM-COUNTER* to zero here.
591 ;; Superficially, this seemed harmful -- the user could reasonably be
592 ;; surprised if *GENSYM-COUNTER* turned back to zero when something was
593 ;; compiled. A closer inspection showed that this actually turned out to be
594 ;; harmless in practice, because CLEAR-STUFF was only called from within
595 ;; forms which bound CL::*GENSYM-COUNTER* to zero. However, this means that
596 ;; even though zeroing CL::*GENSYM-COUNTER* here turned out to be harmless in
597 ;; practice, it was also useless in practice. So we don't do it any more.)
600 \f
601 ;;;; trace output
603 ;;; Print out some useful info about COMPONENT to STREAM.
624 \f
625 ;;;; file reading
626 ;;;;
627 ;;;; When reading from a file, we have to keep track of some source
628 ;;;; information. We also exploit our ability to back up for printing
629 ;;;; the error context and for recovering from errors.
630 ;;;;
631 ;;;; The interface we provide to this stuff is the stream-oid
632 ;;;; SOURCE-INFO structure. The bookkeeping is done as a side effect
633 ;;;; of getting the next source form.
635 ;;; A FILE-INFO structure holds all the source information for a
636 ;;; given file.
638 ;; If a file, the truename of the corresponding source file. If from
639 ;; a Lisp form, :LISP. If from a stream, :STREAM.
641 ;; the defaulted, but not necessarily absolute file name (i.e. prior
642 ;; to TRUENAME call.) Null if not a file. This is used to set
643 ;; *COMPILE-FILE-PATHNAME*, and if absolute, is dumped in the
644 ;; debug-info.
646 ;; the file's write date (if relevant)
648 ;; the source path root number of the first form in this file (i.e.
649 ;; the total number of forms converted previously in this
650 ;; compilation)
652 ;; parallel vectors containing the forms read out of the file and
653 ;; the file positions that reading of each form started at (i.e. the
654 ;; end of the previous form)
658 ;;; The SOURCE-INFO structure provides a handle on all the source
659 ;;; information for an entire compilation.
661 #-no-ansi-print-object
665 ;; the UT that compilation started at
667 ;; the FILE-INFO structure for this compilation
669 ;; the stream that we are using to read the FILE-INFO, or NIL if
670 ;; no stream has been opened yet
673 ;;; Given a pathname, return a SOURCE-INFO structure.
676 :untruename file
681 ;;; Return a SOURCE-INFO to describe the incremental compilation of FORM.
688 ;;; Return a SOURCE-INFO which will read from STREAM.
694 ;;; Return a form read from STREAM; or for EOF use the trick,
695 ;;; popularized by Kent Pitman, of returning STREAM itself. If an
696 ;;; error happens, then convert it to standard abort-the-compilation
697 ;;; error condition (possibly recording some extra location
698 ;;; information).
703 :error condition
704 ;; We don't need to supply :POSITION here because
705 ;; READER-ERRORs already know their position in the file.
706 ))
707 ;; ANSI, in its wisdom, says that READ should return END-OF-FILE
708 ;; (and that this is not a READER-ERROR) when it encounters end of
709 ;; file in the middle of something it's trying to read.
712 :error condition
713 ;; We need to supply :POSITION here because the END-OF-FILE
714 ;; condition doesn't carry the position that the user
715 ;; probably cares about, where the failed READ began.
718 ;;; If STREAM is present, return it, otherwise open a stream to the
719 ;;; current file. There must be a current file.
720 ;;;
721 ;;; FIXME: This is probably an unnecessarily roundabout way to do
722 ;;; things now that we process a single file in COMPILE-FILE (unlike
723 ;;; the old CMU CL code, which accepted multiple files). Also, the old
724 ;;; comment said
725 ;;; When we open a new file, we also reset *PACKAGE* and policy.
726 ;;; This gives the effect of rebinding around each file.
727 ;;; which doesn't seem to be true now. Check to make sure that if
728 ;;; such rebinding is necessary, it's still done somewhere.
738 ;;; Close the stream in INFO if it is open.
746 ;;; Read and compile the source file.
763 nil)))))))
765 ;;; Return the INDEX'th source form read from INFO and the position
766 ;;; where it was read.
772 \f
773 ;;;; processing of top level forms
775 ;;; This is called by top level form processing when we are ready to
776 ;;; actually compile something. If *BLOCK-COMPILE* is T, then we still
777 ;;; convert the form, but delay compilation, pushing the result on
778 ;;; *TOPLEVEL-LAMBDAS* instead.
786 ;;; Macroexpand FORM in the current environment with an error handler.
787 ;;; We only expand one level, so that we retain all the intervening
788 ;;; forms in the source path.
796 condition))))
798 ;;; Process a PROGN-like portion of a top level form. FORMS is a list of
799 ;;; the forms, and PATH is the source path of the FORM they came out of.
800 ;;; COMPILE-TIME-TOO is as in ANSI "3.2.3.1 Processing of Top Level Forms".
806 ;;; Process a top level use of LOCALLY, or anything else (e.g.
807 ;;; MACROLET) at top level which has declarations and ordinary forms.
808 ;;; We parse declarations and then recursively process the body.
814 ;; Binding *POLICY* is pretty much of a hack, since it
815 ;; causes LOCALLY to "capture" enclosed proclamations. It
816 ;; is necessary because CONVERT-AND-MAYBE-COMPILE uses the
817 ;; value of *POLICY* as the policy. The need for this hack
818 ;; is due to the quirk that there is no way to represent in
819 ;; a POLICY that an optimize quality came from the default.
820 ;;
821 ;; FIXME: Ideally, something should be done so that DECLAIM
822 ;; inside LOCALLY works OK. Failing that, at least we could
823 ;; issue a warning instead of silently screwing up.
827 ;;; Parse an EVAL-WHEN situations list, returning three flags,
828 ;;; (VALUES COMPILE-TOPLEVEL LOAD-TOPLEVEL EXECUTE), indicating
829 ;;; the types of situations present in the list.
833 '(:compile-toplevel
834 compile
835 :load-toplevel
836 load
837 :execute
838 eval)))
843 deprecated-names)))
845 situations)
850 ;;; utilities for extracting COMPONENTs of FUNCTIONALs
858 result))
867 &key
868 name
870 ;; I'd thought NIL should
871 ;; work, but it doesn't.
872 ;; -- WHN 2001-09-20
881 definition
883 name)
884 ;; KLUDGE: we do this so that we get to have
885 ;; nice debug returnness in functions defined
886 ;; from the REPL
897 fun)))
899 ;;; Compile LAMBDA-EXPRESSION into *COMPILE-OBJECT*, returning a
900 ;;; description of the result.
901 ;;; * If *COMPILE-OBJECT* is a CORE-OBJECT, then write the function
902 ;;; into core and return the compiled FUNCTION value.
903 ;;; * If *COMPILE-OBJECT* is a fasl file, then write the function
904 ;;; into the fasl file and return a dump handle.
905 ;;;
906 ;;; If NAME is provided, then we try to use it as the name of the
907 ;;; function for debugging/diagnostic information.
910 &key
911 name
913 ;; This magical idiom seems to be the appropriate
914 ;; path for compiling standalone LAMBDAs, judging
915 ;; from the CMU CL code and experiment, so it's a
916 ;; nice default for things where we don't have a
917 ;; real source path (as in e.g. inside CL:COMPILE).
923 :name name
926 ;; FIXME: The compile-it code from here on is sort of a
927 ;; twisted version of the code in COMPILE-TOPLEVEL. It'd be
928 ;; better to find a way to share the code there; or
929 ;; alternatively, to use this code to replace the code there.
930 ;; (The second alternative might be pretty easy if we used
931 ;; the :LOCALL-ONLY option to IR1-FOR-LAMBDA. Then maybe the
932 ;; whole FUNCTIONAL-KIND=:TOPLEVEL case could go away..)
940 ;; FIXME: This is more monkey see monkey do based on CMU CL
941 ;; code. If anyone figures out why to only prescan HAIRY-TOP
942 ;; and TOP-COMPONENTS here, instead of *ALL-COMPONENTS* or
943 ;; some other combination of results from FIND-INITIAL-VALUES,
944 ;; it'd be good to explain it.
960 result
961 ;; KLUDGE: This code duplicates some other code in this
962 ;; file. In the great reorganzation, the flow of program
963 ;; logic changed from the original CMUCL model, and that
964 ;; path (as of sbcl-0.7.5 in SUB-COMPILE-FILE) was no
965 ;; longer followed for CORE-OBJECTS, leading to BUG
966 ;; 156. This place is transparently not the right one for
967 ;; this code, but I don't have a clear enough overview of
968 ;; the compiler to know how to rearrange it all so that
969 ;; this operation fits in nicely, and it was blocking
970 ;; reimplementation of (DECLAIM (INLINE FOO)) (MACROLET
971 ;; ((..)) (DEFUN FOO ...))
972 ;;
973 ;; FIXME: This KLUDGE doesn't solve all the problem in an
974 ;; ideal way, as (1) definitions typed in at the REPL
975 ;; without an INLINE declaration will give a NULL
976 ;; FUNCTION-LAMBDA-EXPRESSION (allowable, but not ideal)
977 ;; and (2) INLINE declarations will yield a
978 ;; FUNCTION-LAMBDA-EXPRESSION headed by
979 ;; SB-C:LAMBDA-WITH-LEXENV, even for null LEXENV. -- CSR,
980 ;; 2002-07-02
981 ;;
982 ;; (2) is probably fairly easy to fix -- it is, after all,
983 ;; a matter of list manipulation (or possibly of teaching
984 ;; CL:FUNCTION about SB-C:LAMBDA-WITH-LEXENV). (1) is
985 ;; significantly harder, as the association between
986 ;; function object and source is a tricky one.
987 ;;
988 ;; FUNCTION-LAMBDA-EXPRESSION "works" (i.e. returns a
989 ;; non-NULL list) when the function in question has been
990 ;; compiled by (COMPILE <x> '(LAMBDA ...)); it does not
991 ;; work when it has been compiled as part of the top-level
992 ;; EVAL strategy of compiling everything inside (LAMBDA ()
993 ;; ...). -- CSR, 2002-11-02
1005 (%compile lambda-expression
1007 :name name
1012 ;;; Process a top level FORM with the specified source PATH.
1013 ;;; * If this is a magic top level form, then do stuff.
1014 ;;; * If this is a macro, then expand it.
1015 ;;; * Otherwise, just compile it.
1016 ;;;
1017 ;;; COMPILE-TIME-TOO is as defined in ANSI
1018 ;;; "3.2.3.1 Processing of Top Level Forms".
1031 path)
1035 ;; When we're cross-compiling, consider: what should we
1036 ;; do when we hit e.g.
1037 ;; (EVAL-WHEN (:COMPILE-TOPLEVEL)
1038 ;; (DEFUN FOO (X) (+ 7 X)))?
1039 ;; DEFUN has a macro definition in the cross-compiler,
1040 ;; and a different macro definition in the target
1041 ;; compiler. The only sensible thing is to use the
1042 ;; target compiler's macro definition, since the
1043 ;; cross-compiler's macro is in general into target
1044 ;; functions which can't meaningfully be executed at
1045 ;; cross-compilation time. So make sure we do the EVAL
1046 ;; here, before we macroexpand.
1047 ;;
1048 ;; Then things get even dicier with something like
1049 ;; (DEFCONSTANT-EQX SB!XC:LAMBDA-LIST-KEYWORDS ..)
1050 ;; where we have to make sure that we don't uncross
1051 ;; the SB!XC: prefix before we do EVAL, because otherwise
1052 ;; we'd be trying to redefine the cross-compilation host's
1053 ;; constants.
1054 ;;
1055 ;; (Isn't it fun to cross-compile Common Lisp?:-)
1056 #+sb-xc-host
1061 ;; like SB!XC:DEFCONSTANT and SB!XC:DEFTYPE
1062 ;; should be equivalent to their CL: counterparts
1063 ;; when being compiled as target code. We leave
1064 ;; the rest of the form uncrossed because macros
1065 ;; might yet expand into EVAL-WHEN stuff, and
1066 ;; things inside EVAL-WHEN can't be uncrossed
1067 ;; until after we've EVALed them in the
1068 ;; cross-compilation host.)
1072 slightly-uncrossed)))
1074 ;; (Now that we're no longer processing toplevel
1075 ;; forms, and hence no longer need to worry about
1076 ;; EVAL-WHEN, we can uncross everything.)
1078 ;; (We have to demote COMPILE-TIME-TOO to NIL
1079 ;; here, no matter what it was before, since
1080 ;; otherwise we'd tend to EVAL subforms more than
1081 ;; once, because of WHEN COMPILE-TIME-TOO form
1082 ;; above.)
1084 ;; When we're not cross-compiling, we only need to
1085 ;; macroexpand once, so we can follow the 1-thru-6
1086 ;; sequence of steps in ANSI's "3.2.3.1 Processing of
1087 ;; Top Level Forms".
1088 #-sb-xc-host
1096 path
1097 compile-time-too))))))
1099 #+sb-xc-host
1100 ;; (There are no xc EVAL-WHEN issues in the ATOM case until
1101 ;; (1) SBCL gets smart enough to handle global
1102 ;; DEFINE-SYMBOL-MACRO or SYMBOL-MACROLET and (2) SBCL
1103 ;; implementors start using symbol macros in a way which
1104 ;; interacts with SB-XC/CL distinction.)
1106 #-sb-xc-host
1112 form))))
1114 ;; In the cross-compiler, top level COLD-FSET arranges
1115 ;; for static linking at cold init time.
1116 #+sb-xc-host
1122 lambda-expression
1123 path)))
1129 ;; CT, LT, and E here are as in Figure 3-7 of ANSI
1130 ;; "3.2.3.1 Processing of Top Level Forms".
1135 e))))
1137 body path new-compile-time-too))
1143 magic
1147 path
1148 compile-time-too))))
1151 magic
1154 path
1155 compile-time-too
1164 \f
1165 ;;;; load time value support
1166 ;;;;
1167 ;;;; (See EMIT-MAKE-LOAD-FORM.)
1169 ;;; Return T if we are currently producing a fasl file and hence
1170 ;;; constants need to be dumped carefully.
1174 ;;; Compile FORM and arrange for it to be called at load-time. Return
1175 ;;; the dumper handle and our best guess at the type of the object.
1185 ;;; Compile the FORMS and arrange for them to be called (for effect,
1186 ;;; not value) at load time.
1191 ;;; Do the actual work of COMPILE-LOAD-TIME-VALUE or
1192 ;;; COMPILE-MAKE-LOAD-FORM-INIT-FORMS.
1198 lambda)))
1200 ;;; This is called by COMPILE-TOPLEVEL when it was passed T for
1201 ;;; LOAD-TIME-VALUE-P (which happens in COMPILE-LOAD-TIME-STUFF). We
1202 ;;; don't try to combine this component with anything else and frob
1203 ;;; the name. If not in a :TOPLEVEL component, then don't bother
1204 ;;; compiling, because it was merged with a run-time component.
1213 \f
1214 ;;;; COMPILE-FILE
1224 ;;; Smash LAMBDAS into a single component, compile it, and arrange for
1225 ;;; the resulting function to be called.
1235 ;;; Compile top level code and call the top level lambdas. We pick off
1236 ;;; top level lambdas in non-top-level components here, calling
1237 ;;; SUB-c-t-l-l on each subsequence of normal top level lambdas.
1246 lambdas
1247 ;; this used to read ":start start", but
1248 ;; start can be greater than len, which
1249 ;; is an error according to ANSI - CSR,
1250 ;; 2002-04-25
1252 len)))
1261 ;;; Compile LAMBDAS (a list of CLAMBDAs for top level forms) into the
1262 ;;; object file.
1263 ;;;
1264 ;;; LOAD-TIME-VALUE-P seems to control whether it's MAKE-LOAD-FORM and
1265 ;;; COMPILE-LOAD-TIME-VALUE stuff. -- WHN 20000201
1299 ;;; Actually compile any stuff that has been queued up for block
1300 ;;; compilation.
1309 ;;; Read all forms from INFO and compile them, with output to OBJECT.
1310 ;;; Return (VALUES NIL WARNINGS-P FAILURE-P).
1332 ;; FIXME: Do we need this rebinding here? It's a literal
1333 ;; translation of the old CMU CL rebinding to
1334 ;; (OR *BACKEND-INFO-ENVIRONMENT* *INFO-ENVIRONMENT*),
1335 ;; and it's not obvious whether the rebinding to itself is
1336 ;; needed that SBCL doesn't need *BACKEND-INFO-ENVIRONMENT*.
1352 nil))
1353 ;; Some errors are sufficiently bewildering that we just fail
1354 ;; immediately, without trying to recover and compile more of
1355 ;; the input file.
1358 "~@<compilation aborted because of input error: ~2I~_~A~:>"
1359 condition)
1362 ;;; Return a pathname for the named file. The file must exist.
1371 new
1384 ;;; Print some junk at the beginning and end of compilation.
1392 file-info)
1394 :print-weekday nil
1400 won
1406 ;;; Open some files and call SUB-COMPILE-FILE. If something unwinds
1407 ;;; out of the compile, then abort the writing of the output file, so
1408 ;;; that we don't overwrite it with known garbage.
1411 &key
1413 ;; ANSI options
1415 ;; FIXME: ANSI doesn't seem to say anything about
1416 ;; *COMPILE-VERBOSE* and *COMPILE-PRINT* being rebound by this
1417 ;; function..
1422 ;; extensions
1426 #!+sb-doc
1427 "Compile INPUT-FILE, producing a corresponding fasl file and returning
1428 its filename. Besides the ANSI &KEY arguments :OUTPUT-FILE, :VERBOSE,
1429 :PRINT, and :EXTERNAL-FORMAT,the following extensions are supported:
1430 :TRACE-FILE
1431 If given, internal data structures are dumped to the specified
1432 file, or if a value of T is given, to a file of *.trace type
1433 derived from the input file name.
1434 Also, as a workaround for vaguely-non-ANSI behavior, the :BLOCK-COMPILE
1435 argument is quasi-supported, to determine whether multiple
1436 functions are compiled together as a unit, resolving function
1437 references at compile time. NIL means that global function names
1438 are never resolved at compilation time. Currently NIL is the
1441 circumstances, the compiler's runtime scales badly when it
1442 tries to do this for large files. If/when this performance
1443 problem is fixed, the block compilation default behavior will
1444 probably be made dependent on the SPEED and COMPILATION-SPEED
1445 optimization values, and the :BLOCK-COMPILE argument will probably
1446 become deprecated."
1473 default-trace-file-pathname
1475 default-trace-file-pathname))))
1484 dummy)
1505 ;; Hack around filesystem race condition...
1507 nil)
1508 warnings-p
1509 failure-p)))
1510 \f
1511 ;;; a helper function for COMPILE-FILE-PATHNAME: the default for
1512 ;;; the OUTPUT-FILE argument
1513 ;;;
1514 ;;; ANSI: The defaults for the OUTPUT-FILE are taken from the pathname
1515 ;;; that results from merging the INPUT-FILE with the value of
1516 ;;; *DEFAULT-PATHNAME-DEFAULTS*, except that the type component should
1517 ;;; default to the appropriate implementation-defined default type for
1518 ;;; compiled files.
1522 retyped))
1524 ;;; KLUDGE: Part of the ANSI spec for this seems contradictory:
1525 ;;; If INPUT-FILE is a logical pathname and OUTPUT-FILE is unsupplied,
1526 ;;; the result is a logical pathname. If INPUT-FILE is a logical
1527 ;;; pathname, it is translated into a physical pathname as if by
1528 ;;; calling TRANSLATE-LOGICAL-PATHNAME.
1529 ;;; So I haven't really tried to make this precisely ANSI-compatible
1530 ;;; at the level of e.g. whether it returns logical pathname or a
1531 ;;; physical pathname. Patches to make it more correct are welcome.
1532 ;;; -- WHN 2000-12-09
1534 &key
1536 input-file))
1538 #!+sb-doc
1539 "Return a pathname describing what file COMPILE-FILE would write to given
1540 these arguments."
1542 \f
1543 ;;;; MAKE-LOAD-FORM stuff
1545 ;;; The entry point for MAKE-LOAD-FORM support. When IR1 conversion
1546 ;;; finds a constant structure, it invokes this to arrange for proper
1547 ;;; dumping. If it turns out that the constant has already been
1548 ;;; dumped, then we don't need to do anything.
1549 ;;;
1550 ;;; If the constant hasn't been dumped, then we check to see whether
1551 ;;; we are in the process of creating it. We detect this by
1552 ;;; maintaining the special *CONSTANTS-BEING-CREATED* as a list of all
1553 ;;; the constants we are in the process of creating. Actually, each
1554 ;;; entry is a list of the constant and any init forms that need to be
1555 ;;; processed on behalf of that constant.
1556 ;;;
1557 ;;; It's not necessarily an error for this to happen. If we are
1558 ;;; processing the init form for some object that showed up *after*
1559 ;;; the original reference to this constant, then we just need to
1560 ;;; defer the processing of that init form. To detect this, we
1561 ;;; maintain *CONSTANTS-CREATED-SINCE-LAST-INIT* as a list of the
1562 ;;; constants created since the last time we started processing an
1563 ;;; init form. If the constant passed to emit-make-load-form shows up
1564 ;;; in this list, then there is a circular chain through creation
1565 ;;; forms, which is an error.
1566 ;;;
1567 ;;; If there is some intervening init form, then we blow out of
1568 ;;; processing it by throwing to the tag PENDING-INIT. The value we
1569 ;;; throw is the entry from *CONSTANTS-BEING-CREATED*. This is so the
1570 ;;; offending init form can be tacked onto the init forms for the
1571 ;;; circular object.
1572 ;;;
1573 ;;; If the constant doesn't show up in *CONSTANTS-BEING-CREATED*, then
1574 ;;; we have to create it. We call MAKE-LOAD-FORM and check to see
1575 ;;; whether the creation form is the magic value
1576 ;;; :SB-JUST-DUMP-IT-NORMALLY. If it is, then we don't do anything. The
1577 ;;; dumper will eventually get its hands on the object and use the
1578 ;;; normal structure dumping noise on it.
1579 ;;;
1580 ;;; Otherwise, we bind *CONSTANTS-BEING-CREATED* and
1581 ;;; *CONSTANTS-CREATED-SINCE- LAST-INIT* and compile the creation form
1582 ;;; much the way LOAD-TIME-VALUE does. When this finishes, we tell the
1583 ;;; dumper to use that result instead whenever it sees this constant.
1584 ;;;
1585 ;;; Now we try to compile the init form. We bind
1586 ;;; *CONSTANTS-CREATED-SINCE-LAST-INIT* to NIL and compile the init
1587 ;;; form (and any init forms that were added because of circularity
1588 ;;; detection). If this works, great. If not, we add the init forms to
1589 ;;; the init forms for the object that caused the problems and let it
1590 ;;; deal with it.
1593 ;;; FIXME: Shouldn't these^ variables be unbound outside LET forms?
1597 ;; KLUDGE: This special hack is because I was too lazy
1598 ;; to rework DEF!STRUCT so that the MAKE-LOAD-FORM
1599 ;; function of LAYOUT returns nontrivial forms when
1600 ;; building the cross-compiler but :IGNORE-IT when
1601 ;; cross-compiling or running under the target Lisp. --
1602 ;; WHN 19990914
1614 constant
1615 condition)))
1617 (:sb-just-dump-it-normally
1619 t)
1620 (:ignore-it
1621 nil)
1638 constant
1640 creation-form)
1642 nil)
1644 constant)))
1650 collect name into names
1651 collect form into forms
1653 nil)))
1658 \f
1659 ;;;; Host compile time definitions
1660 #+sb-xc-host
1665 #+sb-xc-host