| blob | 51373939ce787f68c7f12db0b66036918dc77f85 |
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?
32 ;;; Whether reference to a thing which cannot be defined causes a full
33 ;;; warning.
38 ;;; Set to NIL to disable loop analysis for register allocation.
41 ;;; Bind this to a stream to capture various internal debugging output.
44 ;;; The current block compilation state. These are initialized to the
45 ;;; :BLOCK-COMPILE and :ENTRY-POINTS arguments that COMPILE-FILE was
46 ;;; called with.
47 ;;;
48 ;;; *BLOCK-COMPILE-ARG* holds the original value of the :BLOCK-COMPILE
49 ;;; argument, which overrides any internal declarations.
56 ;;; When block compiling, used by PROCESS-FORM to accumulate top level
57 ;;; lambdas resulting from compiling subforms. (In reverse order.)
61 ;;; The current non-macroexpanded toplevel form as printed when
62 ;;; *compile-print* is true.
66 #!+sb-doc
69 #!+sb-doc
72 #!+sb-doc
73 "When this is true, the compiler prints to *STANDARD-OUTPUT* progress
74 information about the phases of compilation of each function. (This
78 #!+sb-doc
79 "The defaulted pathname of the file currently being compiled, or NIL if not
82 #!+sb-doc
83 "The TRUENAME of the file currently being compiled, or NIL if not
90 ;;; the SOURCE-INFO structure for the current compilation. This is
91 ;;; null globally to indicate that we aren't currently in any
92 ;;; identifiable compilation.
95 ;;; This is true if we are within a WITH-COMPILATION-UNIT form (which
96 ;;; normally causes nested uses to be no-ops).
99 ;;; Count of the number of compilation units dynamically enclosed by
100 ;;; the current active WITH-COMPILATION-UNIT that were unwound out of.
103 ;;; Mumble conditional on *COMPILE-PROGRESS*.
120 ;; Used during compilation to map code paths to the matching
121 ;; instrumentation conses.
123 ;; Used during compilation to keep track of with source paths have been
124 ;; instrumented in which blocks.
126 ;; Stores the code coverage instrumentation results. Keys are namestrings,
127 ;; the value is a list of (CONS PATH STATE), where STATE is NIL for
128 ;; a path that has not been visited, and T for one that has.
131 \f
132 ;;;; WITH-COMPILATION-UNIT and WITH-COMPILATION-VALUES
135 #!+sb-doc
136 "Affects compilations that take place within its dynamic extent. It is
137 intended to be eg. wrapped around the compilation of all files in the same system.
139 Following options are defined:
141 :OVERRIDE Boolean-Form
142 One of the effects of this form is to delay undefined warnings until the
143 end of the form, instead of giving them at the end of each compilation.
144 If OVERRIDE is NIL (the default), then the outermost
145 WITH-COMPILATION-UNIT form grabs the undefined warnings. Specifying
146 OVERRIDE true causes that form to grab any enclosed warnings, even if it
147 is enclosed by another WITH-COMPILATION-UNIT.
149 :POLICY Optimize-Declaration-Form
150 Provides dynamic scoping for global compiler optimization qualities and
151 restrictions, limiting effects of subsequent OPTIMIZE proclamations and
152 calls to SB-EXT:RESTRICT-COMPILER-POLICY to the dynamic scope of BODY.
154 If OVERRIDE is false, specified POLICY is merged with current global
155 policy. If OVERRIDE is true, current global policy, including any
156 restrictions, is discarded in favor of the specified POLICY.
158 Supplying POLICY NIL is equivalent to the option not being supplied at
159 all, ie. dynamic scoping of policy does not take place.
161 This option is an SBCL-specific experimental extension: Interface
162 subject to change.
164 :SOURCE-NAMESTRING Namestring-Form
165 Attaches the value returned by the Namestring-Form to the internal
166 debug-source information as the namestring of the source file. Normally
167 the namestring of the input-file for COMPILE-FILE is used: this option
168 can be used to provide source-file information for functions compiled
169 using COMPILE, or to override the input-file of COMPILE-FILE.
171 If both an outer and an inner WITH-COMPILATION-UNIT provide a
172 SOURCE-NAMESTRING, the inner one takes precedence. Unaffected
173 by :OVERRIDE.
175 This is an SBCL-specific extension.
177 :SOURCE-PLIST Plist-Form
178 Attaches the value returned by the Plist-Form to internal debug-source
179 information of functions compiled in within the dynamic extent of BODY.
181 Primarily for use by development environments, in order to eg. associate
182 function definitions with editor-buffers. Can be accessed using
183 SB-INTROSPECT:DEFINITION-SOURCE-PLIST.
185 If an outer WITH-COMPILATION-UNIT form also provide a SOURCE-PLIST, it
186 is appended to the end of the provided SOURCE-PLIST. Unaffected
187 by :OVERRIDE.
189 This is an SBCL-specific extension.
191 Examples:
193 ;; Prevent proclamations from the file leaking, and restrict
194 ;; SAFETY to 3 -- otherwise uses the current global policy.
195 (with-compilation-unit (:policy '(optimize))
196 (restrict-compiler-policy 'safety 3)
199 ;; Using default policy instead of the current global one,
200 ;; except for DEBUG 3.
201 (with-compilation-unit (:policy '(optimize debug)
202 :override t)
205 ;; Same as if :POLICY had not been specified at all: SAFETY 3
206 ;; proclamation leaks out from WITH-COMPILATION-UNIT.
207 (with-compilation-unit (:policy nil)
208 (declaim (optimize safety))
210 "
223 ;; Inside another WITH-COMPILATION-UNIT, a WITH-COMPILATION-UNIT is
224 ;; ordinarily (unless OVERRIDE) basically a no-op.
252 ;;; Is NAME something that no conforming program can rely on
253 ;;; defining?
256 (:function
259 (:type
266 ;;; This is to be called at the end of a compilation unit. It signals
267 ;;; any residual warnings about unknown stuff, then prints the total
268 ;;; error counts. ABORT-P should be true when the compilation unit was
269 ;;; aborted by throwing out. ABORT-COUNT is the number of dynamically
270 ;;; enclosed nested compilation units that were aborted.
297 #+sb-xc-host nil
299 (:function
301 "~@<The function ~S is undefined, and its name is ~
302 reserved by ANSI CL so that even if it were ~
303 defined later, the code doing so would not be ~
305 (:type
308 "~@<Undefined type ~S. The name starts with ~S: ~
309 probably use of a quoted type name in a context ~
310 where the name is not evaluated.~:@>"
313 "~@<Undefined type ~S. Note that name ~S is ~
314 reserved by ANSI CL, so code defining a type with ~
315 that name would not be portable.~:@>" name
316 name))))
325 "~W more use~:P of undefined ~(~A~) ~S"
326 more kind name)
328 "~W more use~:P of undefined ~(~A~) ~S"
329 more kind name))))))))))
339 abort-p)
343 "~& Undefined ~(~A~)~p:~
344 ~% ~{~<~% ~1:;~S~>~^ ~}"
347 ~[~:;~:*~& caught ~W ERROR condition~:P~]~
348 ~[~:;~:*~& caught ~W WARNING condition~:P~]~
349 ~[~:;~:*~& caught ~W STYLE-WARNING condition~:P~]~
350 ~[~:;~:*~& printed ~W note~:P~]"
359 ;; Bidrectional map between IR1/IR2/assembler abstractions
360 ;; and a corresponding small integer identifier. One direction could be done
361 ;; by adding the integer ID as an object slot, but we want both directions.
377 ;;; Evaluate BODY, then return (VALUES BODY-VALUE WARNINGS-P
378 ;;; FAILURE-P), where BODY-VALUE is the first value of the body, and
379 ;;; WARNINGS-P and FAILURE-P are as in CL:COMPILE or CL:COMPILE-FILE.
381 ;; This binding could just as well be in WITH-IR1-NAMESPACE, but
382 ;; since it's primarily a debugging tool, it's nicer to have
383 ;; a wider unique scope by ID.
400 ;;; THING is a kind of thing about which we'd like to issue a warning,
401 ;;; but showing at most one warning for a given set of <THING,FMT,ARGS>.
402 ;;; The compiler does a good job of making sure not to print repetitive
403 ;;; warnings for code that it compiles, but this solves a different problem.
404 ;;; Specifically, for a warning from PARSE-LAMBDA-LIST, there are three calls:
405 ;;; - once in the expander for defmacro itself, as it calls MAKE-MACRO-LAMBDA
406 ;;; which calls PARSE-LAMBDA-LIST. This is the toplevel form processing.
407 ;;; - again for :compile-toplevel, where the DS-BIND calls PARSE-LAMBDA-LIST.
408 ;;; If compiling in compile-toplevel, then *COMPILE-OBJECT* is a core object,
409 ;;; but if interpreting, then it is still a fasl.
410 ;;; - once for compiling to fasl. *COMPILE-OBJECT* is a fasl.
411 ;;; I'd have liked the data to be associated with the fasl, except that
412 ;;; as indicated above, the second line hides some information.
420 ;; THING is compared by EQ, FMT by STRING=.
423 ;; We don't want to walk into default values,
424 ;; e.g. (&optional (b #<insane-struct))
425 ;; because #<insane-struct> might be circular.
434 \f
435 ;;;; component compilation
438 #!+sb-doc
439 "The upper limit on the number of times that we will consecutively do IR1
440 optimization that doesn't introduce any new code. A finite limit is
446 ;;; Repeatedly optimize COMPONENT until no further optimizations can
447 ;;; be found or we hit our iteration limit. When we hit the limit, we
448 ;;; clear the component and block REOPTIMIZE flags to discourage the
449 ;;; next optimization attempt from pounding on the same code.
493 ;;; KLUDGE: This was bumped from 5 to 10 in a DTC patch ported by MNA
494 ;;; from CMU CL into sbcl-0.6.11.44, the same one which allowed IR1
495 ;;; transforms to be delayed. Either DTC or MNA or both didn't explain
496 ;;; why, and I don't know what the rationale was. -- WHN 2001-04-28
497 ;;;
498 ;;; FIXME: It would be good to document why it's important to have a
499 ;;; large value here, and what the drawbacks of an excessively large
500 ;;; value are; and it might also be good to make it depend on
501 ;;; optimization policy.
507 ;;; Iterate doing FIND-DFO until no new dead code is discovered.
520 ;;; Do all the IR1 phases for a non-top-level component.
525 ;make this 0.
548 ;; We delay the generation of type checks until
549 ;; the type constraints have had time to
550 ;; propagate, else the compiler can confuse itself.
575 #!+inline-constants
577 #!+inline-constants
579 #!+inline-constants
594 ;; Assign BLOCK-NUMBER for any cleanup blocks introduced by
595 ;; stack analysis. There shouldn't be any unreachable code after
596 ;; control, so this won't delete anything.
647 #-sb-xc-host
659 code-length
660 fixup-notes
667 code-length
668 fixup-notes
672 ;; We're done, so don't bother keeping anything around.
677 ;;; Delete components with no external entry points before we try to
678 ;;; generate code. Unreachable closures can cause IR2 conversion to
679 ;;; puke on itself, since it is the reference to the closure which
680 ;;; normally causes the components to be combined.
687 (:external
695 ;; miscellaneous sanity checks
696 ;;
697 ;; FIXME: These are basically pretty wimpy compared to the checks done
698 ;; by the old CHECK-IR1-CONSISTENCY code. It would be really nice to
699 ;; make those internal consistency checks work again and use them.
704 ;; sanity check to prevent weirdness from propagating insidiously as
705 ;; far from its root cause as it did in bug 138: Make sure that
706 ;; thing-to-COMPONENT links are consistent.
712 ;; Record xref information before optimization. This way the
713 ;; stored xref data reflects the real source as closely as
714 ;; possible.
724 #|
736 |#
738 ;; This should happen at some point before PHYSENV-ANALYZE, and
739 ;; after RECORD-COMPONENT-XREFS. Beyond that, I haven't really
740 ;; thought things through. -- AJB, 2014-Jun-08
743 ;; FIXME: What is MAYBE-MUMBLE for? Do we need it any more?
757 \f
758 ;;;; clearing global data structures
759 ;;;;
760 ;;;; FIXME: Is it possible to get rid of this stuff, getting rid of
761 ;;;; global data structures entirely when possible and consing up the
762 ;;;; others from scratch instead of clearing and reusing them?
764 ;;; Clear the INFO in constants in the *FREE-VARS*, etc. In
765 ;;; addition to allowing stuff to be reclaimed, this is required for
766 ;;; correct assignment of constant offsets, since we need to assign a
767 ;;; new offset for each component. We don't clear the FUNCTIONAL-INFO
768 ;;; slots, since they are used to keep track of functions across
769 ;;; component boundaries.
784 ;;; Blow away the REFS for all global variables, and let COMPONENT
785 ;;; be recycled.
797 x))
804 \f
805 ;;;; trace output
807 ;;; Print out some useful info about COMPONENT to STREAM.
828 \f
829 ;;; Given a pathname, return a SOURCE-INFO structure.
834 :external-format external-format
835 :subforms
840 ;;; Return a SOURCE-INFO to describe the incremental compilation of FORM.
848 ;;; Walk up the SOURCE-INFO list until we either reach a SOURCE-INFO
849 ;;; with no parent (e.g., from a REPL evaluation) or until we reach a
850 ;;; SOURCE-INFO whose FILE-INFO denotes a file.
858 finfo))))
860 ;;; If STREAM is present, return it, otherwise open a stream to the
861 ;;; current file. There must be a current file.
862 ;;;
863 ;;; FIXME: This is probably an unnecessarily roundabout way to do
864 ;;; things now that we process a single file in COMPILE-FILE (unlike
865 ;;; the old CMU CL code, which accepted multiple files). Also, the old
866 ;;; comment said
867 ;;; When we open a new file, we also reset *PACKAGE* and policy.
868 ;;; This gives the effect of rebinding around each file.
869 ;;; which doesn't seem to be true now. Check to make sure that if
870 ;;; such rebinding is necessary, it's still done somewhere.
883 :external-format external-format
884 ;; SBCL stream classes aren't available in the host
890 stream)))))
892 ;;; Close the stream in INFO if it is open.
900 ;; Loop over forms read from INFO's stream, calling FUNCTION with each.
901 ;; CONDITION-NAME is signaled if there is a reader error, and should be
902 ;; a subtype of not-so-aptly-named INPUT-ERROR-IN-COMPILE-FILE.
909 ;; Return a form read from STREAM; or for EOF use the trick,
910 ;; popularized by Kent Pitman, of returning STREAM itself.
913 ;; Reset for a new toplevel form.
921 ;; We don't need to supply :POSITION here because
922 ;; READER-ERRORs already know their position in the file.
923 :condition condition
925 ;; ANSI, in its wisdom, says that READ should return END-OF-FILE
926 ;; (and that this is not a READER-ERROR) when it encounters end of
927 ;; file in the middle of something it's trying to read,
928 ;; making it unfortunately indistinguishable from legal EOF.
929 ;; Were it not for that, it would be more elegant to just
930 ;; handle one more condition in the HANDLER-CASE.
933 condition-name
934 :condition condition
935 ;; We need to supply :POSITION here because the END-OF-FILE
936 ;; condition doesn't carry the position that the user
937 ;; probably cares about, where the failed READ began.
938 :position
941 pos)
945 stream
950 :current-index
956 current-idx))
959 ;;; Loop over FORMS retrieved from INFO. Used by COMPILE-FILE and
960 ;;; LOAD when loading from a FILE-STREAM associated with a source
961 ;;; file. ON-ERROR is the name of a condition class that should
962 ;;; be signaled if anything goes wrong during a READ.
973 ;;; Read and compile the source file.
981 ;; It's easy to get into a situation where cold-init crashes and the only
982 ;; backtrace you get from ldb is TOP-LEVEL-FORM, which means you're anywhere
983 ;; within the 23000 or so blobs of code deferred until cold-init.
984 ;; Seeing each file finish narrows things down without the noise of :sb-show,
985 ;; but this hack messes up form positions, so it's not on unless asked for.
1000 ;;; Return the INDEX'th source form read from INFO and the position
1001 ;;; where it was read.
1007 \f
1008 ;;;; processing of top level forms
1010 ;;; This is called by top level form processing when we are ready to
1011 ;;; actually compile something. If *BLOCK-COMPILE* is T, then we still
1012 ;;; convert the form, but delay compilation, pushing the result on
1013 ;;; *TOPLEVEL-LAMBDAS* instead.
1016 #+sb-xc-host
1020 ;; Don't bother to compile simple objects that just sit there.
1034 nil))))))
1036 ;;; Macroexpand FORM in the current environment with an error handler.
1037 ;;; We only expand one level, so that we retain all the intervening
1038 ;;; forms in the source path. A compiler-macro takes precedence over
1039 ;;; an ordinary macro as specified in CLHS 3.2.3.1
1040 ;;; Note that this function is _only_ for processing of toplevel forms.
1041 ;;; Non-toplevel forms use IR1-CONVERT-FUNCTOID which considers compiler macros.
1054 condition))))
1056 ;;; Process a PROGN-like portion of a top level form. FORMS is a list of
1057 ;;; the forms, and PATH is the source path of the FORM they came out of.
1058 ;;; COMPILE-TIME-TOO is as in ANSI "3.2.3.1 Processing of Top Level Forms".
1064 ;;; Process a top level use of LOCALLY, or anything else (e.g.
1065 ;;; MACROLET) at top level which has declarations and ordinary forms.
1066 ;;; We parse declarations and then recursively process the body.
1072 ;; FIXME: VALUES declaration
1073 ;;
1074 ;; Binding *POLICY* is pretty much of a hack, since it
1075 ;; causes LOCALLY to "capture" enclosed proclamations. It
1076 ;; is necessary because CONVERT-AND-MAYBE-COMPILE uses the
1077 ;; value of *POLICY* as the policy. The need for this hack
1078 ;; is due to the quirk that there is no way to represent in
1079 ;; a POLICY that an optimize quality came from the default.
1080 ;;
1081 ;; FIXME: Ideally, something should be done so that DECLAIM
1082 ;; inside LOCALLY works OK. Failing that, at least we could
1083 ;; issue a warning instead of silently screwing up.
1084 ;; Here's how to fix this: a POLICY object can in fact represent
1085 ;; absence of qualitities. Whenever we rebind *POLICY* (here and
1086 ;; elsewhere), it should be bound to a policy that expresses no
1087 ;; qualities. Proclamations should update SYMBOL-GLOBAL-VALUE of
1088 ;; *POLICY*, which can be seen irrespective of dynamic bindings,
1089 ;; and declarations should update the lexical policy.
1090 ;; The POLICY macro can be amended to merge the dynamic *POLICY*
1091 ;; (or whatever it came from, like a LEXENV) with the global
1092 ;; *POLICY*. COERCE-TO-POLICY can do the merge, employing a 1-line
1093 ;; cache so that repeated calls for any two fixed policy objects
1094 ;; return the identical value (since policies are immutable).
1096 ;; This is probably also a hack
1098 ;; ditto
1102 ;;; Parse an EVAL-WHEN situations list, returning three flags,
1103 ;;; (VALUES COMPILE-TOPLEVEL LOAD-TOPLEVEL EXECUTE), indicating
1104 ;;; the types of situations present in the list.
1108 '(:compile-toplevel
1109 compile
1110 :load-toplevel
1111 load
1112 :execute
1113 eval)))
1118 deprecated-names)))
1120 situations)
1125 ;;; utilities for extracting COMPONENTs of FUNCTIONALs
1136 result))))
1140 result))))
1143 &key
1144 name
1146 ;; I'd thought NIL should
1147 ;; work, but it doesn't.
1148 ;; -- WHN 2001-09-20
1159 lambda-expression
1161 ;; Convert the XEP using the policy of the real function. Otherwise
1162 ;; the wrong policy will be used for deciding whether to type-check
1163 ;; the parameters of the real function (via CONVERT-CALL /
1164 ;; PROPAGATE-TO-ARGS). -- JES, 2007-02-27
1167 :source-name source-name
1179 ;; Any leftover REFs to FUN outside local calls get replaced with the
1180 ;; XEP.
1187 xep
1188 fun)
1189 xep)))
1191 ;;; Compile LAMBDA-EXPRESSION into *COMPILE-OBJECT*, returning a
1192 ;;; description of the result.
1193 ;;; * If *COMPILE-OBJECT* is a CORE-OBJECT, then write the function
1194 ;;; into core and return the compiled FUNCTION value.
1195 ;;; * If *COMPILE-OBJECT* is a fasl file, then write the function
1196 ;;; into the fasl file and return a dump handle.
1197 ;;;
1198 ;;; If NAME is provided, then we try to use it as the name of the
1199 ;;; function for debugging/diagnostic information.
1202 &key
1203 name
1205 ;; This magical idiom seems to be the appropriate
1206 ;; path for compiling standalone LAMBDAs, judging
1207 ;; from the CMU CL code and experiment, so it's a
1208 ;; nice default for things where we don't have a
1209 ;; real source path (as in e.g. inside CL:COMPILE).
1220 :name name
1223 ;; FIXME: The compile-it code from here on is sort of a
1224 ;; twisted version of the code in COMPILE-TOPLEVEL. It'd be
1225 ;; better to find a way to share the code there; or
1226 ;; alternatively, to use this code to replace the code there.
1227 ;; (The second alternative might be pretty easy if we used
1228 ;; the :LOCALL-ONLY option to IR1-FOR-LAMBDA. Then maybe the
1229 ;; whole FUNCTIONAL-KIND=:TOPLEVEL case could go away..)
1247 result
1248 ;; KLUDGE: This code duplicates some other code in this
1249 ;; file. In the great reorganzation, the flow of program
1250 ;; logic changed from the original CMUCL model, and that
1251 ;; path (as of sbcl-0.7.5 in SUB-COMPILE-FILE) was no
1252 ;; longer followed for CORE-OBJECTS, leading to BUG
1253 ;; 156. This place is transparently not the right one for
1254 ;; this code, but I don't have a clear enough overview of
1255 ;; the compiler to know how to rearrange it all so that
1256 ;; this operation fits in nicely, and it was blocking
1257 ;; reimplementation of (DECLAIM (INLINE FOO)) (MACROLET
1258 ;; ((..)) (DEFUN FOO ...))
1259 ;;
1260 ;; FIXME: This KLUDGE doesn't solve all the problem in an
1261 ;; ideal way, as (1) definitions typed in at the REPL
1262 ;; without an INLINE declaration will give a NULL
1263 ;; FUNCTION-LAMBDA-EXPRESSION (allowable, but not ideal)
1264 ;; and (2) INLINE declarations will yield a
1265 ;; FUNCTION-LAMBDA-EXPRESSION headed by
1266 ;; SB-C:LAMBDA-WITH-LEXENV, even for null LEXENV. -- CSR,
1267 ;; 2002-07-02
1268 ;;
1269 ;; (2) is probably fairly easy to fix -- it is, after all,
1270 ;; a matter of list manipulation (or possibly of teaching
1271 ;; CL:FUNCTION about SB-C:LAMBDA-WITH-LEXENV). (1) is
1272 ;; significantly harder, as the association between
1273 ;; function object and source is a tricky one.
1274 ;;
1275 ;; FUNCTION-LAMBDA-EXPRESSION "works" (i.e. returns a
1276 ;; non-NULL list) when the function in question has been
1277 ;; compiled by (COMPILE <x> '(LAMBDA ...)); it does not
1278 ;; work when it has been compiled as part of the top-level
1279 ;; EVAL strategy of compiling everything inside (LAMBDA ()
1280 ;; ...). -- CSR, 2002-11-02
1297 form)
1306 form)
1310 ;;; Handle the evaluation the a :COMPILE-TOPLEVEL body during
1311 ;;; compilation. Normally just evaluate in the appropriate
1312 ;;; environment, but also compile if outputting a CFASL.
1327 ;; In case a null lexenv is created, it needs to get the newly
1328 ;; effective global policy, not the policy currently in *POLICY*.
1332 ;;; Process a top level FORM with the specified source PATH.
1333 ;;; * If this is a magic top level form, then do stuff.
1334 ;;; * If this is a macro, then expand it.
1335 ;;; * Otherwise, just compile it.
1336 ;;;
1337 ;;; COMPILE-TIME-TOO is as defined in ANSI
1338 ;;; "3.2.3.1 Processing of Top Level Forms".
1349 path)
1354 ;; When we're cross-compiling, consider: what should we
1355 ;; do when we hit e.g.
1356 ;; (EVAL-WHEN (:COMPILE-TOPLEVEL)
1357 ;; (DEFUN FOO (X) (+ 7 X)))?
1358 ;; DEFUN has a macro definition in the cross-compiler,
1359 ;; and a different macro definition in the target
1360 ;; compiler. The only sensible thing is to use the
1361 ;; target compiler's macro definition, since the
1362 ;; cross-compiler's macro is in general into target
1363 ;; functions which can't meaningfully be executed at
1364 ;; cross-compilation time. So make sure we do the EVAL
1365 ;; here, before we macroexpand.
1366 ;;
1367 ;; Then things get even dicier with something like
1368 ;; (DEFCONSTANT-EQX SB!XC:LAMBDA-LIST-KEYWORDS ..)
1369 ;; where we have to make sure that we don't uncross
1370 ;; the SB!XC: prefix before we do EVAL, because otherwise
1371 ;; we'd be trying to redefine the cross-compilation host's
1372 ;; constants.
1373 ;;
1374 ;; (Isn't it fun to cross-compile Common Lisp?:-)
1375 #+sb-xc-host
1380 ;; like SB!XC:DEFCONSTANT and SB!XC:DEFTYPE
1381 ;; should be equivalent to their CL: counterparts
1382 ;; when being compiled as target code. We leave
1383 ;; the rest of the form uncrossed because macros
1384 ;; might yet expand into EVAL-WHEN stuff, and
1385 ;; things inside EVAL-WHEN can't be uncrossed
1386 ;; until after we've EVALed them in the
1387 ;; cross-compilation host.)
1391 slightly-uncrossed)))
1393 ;; (Now that we're no longer processing toplevel
1394 ;; forms, and hence no longer need to worry about
1395 ;; EVAL-WHEN, we can uncross everything.)
1397 ;; (We have to demote COMPILE-TIME-TOO to NIL
1398 ;; here, no matter what it was before, since
1399 ;; otherwise we'd tend to EVAL subforms more than
1400 ;; once, because of WHEN COMPILE-TIME-TOO form
1401 ;; above.)
1403 ;; When we're not cross-compiling, we only need to
1404 ;; macroexpand once, so we can follow the 1-thru-6
1405 ;; sequence of steps in ANSI's "3.2.3.1 Processing of
1406 ;; Top Level Forms".
1407 #-sb-xc-host
1415 path
1416 compile-time-too)))))))
1418 #+sb-xc-host
1419 ;; (There are no xc EVAL-WHEN issues in the ATOM case until
1420 ;; (1) SBCL gets smart enough to handle global
1421 ;; DEFINE-SYMBOL-MACRO or SYMBOL-MACROLET and (2) SBCL
1422 ;; implementors start using symbol macros in a way which
1423 ;; interacts with SB-XC/CL distinction.)
1425 #-sb-xc-host
1431 form))))
1438 ;; CT, LT, and E here are as in Figure 3-7 of ANSI
1439 ;; "3.2.3.1 Processing of Top Level Forms".
1444 e))))
1446 body path new-compile-time-too))
1451 magic
1456 path
1457 compile-time-too))
1461 magic
1465 path
1466 compile-time-too
1476 \f
1477 ;;;; load time value support
1478 ;;;;
1479 ;;;; (See EMIT-MAKE-LOAD-FORM.)
1481 ;;; Return T if we are currently producing a fasl file and hence
1482 ;;; constants need to be dumped carefully.
1486 ;;; Compile FORM and arrange for it to be called at load-time. Return
1487 ;;; the dumper handle and our best guess at the type of the object.
1488 ;;; It would be nice if L-T-V forms were generally eligible
1489 ;;; for fopcompilation, as it could eliminate special cases below.
1493 ;; Ideally any ltv would test FOPCOMPILABLE-P on its form,
1494 ;; but be that as it may, this case is picked off because of
1495 ;; its importance during cross-compilation to ensure that
1496 ;; compiled lambdas don't cause a chicken-and-egg problem.
1499 #+sb-xc-host
1504 ;; Special case for the cross-compiler, necessary for at least
1505 ;; SETUP-PRINTER-STATE, but also anything that would be dumped
1506 ;; using FOP-KNOWN-FUN in the target compiler, to avoid going
1507 ;; through an fdefn.
1508 ;; I'm pretty sure that as of change 00298ec6, it works to
1509 ;; compile #'F before the defun would have been seen by Genesis.
1510 #+sb-xc-host
1525 ;;; Compile the FORMS and arrange for them to be called (for effect,
1526 ;;; not value) at load time.
1531 ;;; Do the actual work of COMPILE-LOAD-TIME-VALUE or
1532 ;;; COMPILE-MAKE-LOAD-FORM-INIT-FORMS.
1538 lambda)))
1540 ;;; This is called by COMPILE-TOPLEVEL when it was passed T for
1541 ;;; LOAD-TIME-VALUE-P (which happens in COMPILE-LOAD-TIME-STUFF). We
1542 ;;; don't try to combine this component with anything else and frob
1543 ;;; the name. If not in a :TOPLEVEL component, then don't bother
1544 ;;; compiling, because it was merged with a run-time component.
1553 \f
1554 ;;;; COMPILE-FILE
1564 ;;; Smash LAMBDAS into a single component, compile it, and arrange for
1565 ;;; the resulting function to be called.
1575 ;;; Compile top level code and call the top level lambdas. We pick off
1576 ;;; top level lambdas in non-top-level components here, calling
1577 ;;; SUB-c-t-l-l on each subsequence of normal top level lambdas.
1586 lambdas
1587 ;; this used to read ":start start", but
1588 ;; start can be greater than len, which
1589 ;; is an error according to ANSI - CSR,
1590 ;; 2002-04-25
1592 len)))
1601 ;;; Compile LAMBDAS (a list of CLAMBDAs for top level forms) into the
1602 ;;; object file.
1603 ;;;
1604 ;;; LOAD-TIME-VALUE-P seems to control whether it's MAKE-LOAD-FORM and
1605 ;;; COMPILE-LOAD-TIME-VALUE stuff. -- WHN 20000201
1638 ;;; Actually compile any stuff that has been queued up for block
1639 ;;; compilation.
1658 lexenv))
1659 ;; Is this right? I would think that if lexenv is null
1660 ;; we should look at *HANDLED-CONDITIONS*.
1683 ;; WOULD-MUFFLE-P is called (incorrectly) only by NOTE-UNDEFINED-REFERENCE.
1684 ;; It is not wrong per se, but as used, it is wrong, making it nearly
1685 ;; impossible to muffle a subset of undefind warnings whose NAME and KIND
1686 ;; slots match specific things tested by a user-defined predicate.
1687 ;; Attempting to do that might muffle everything, depending on how your
1688 ;; predicate responds to a vanilla WARNING. Consider e.g.
1689 ;; (AND WARNING (NOT (SATISFIES HAIRYFN)))
1690 ;; where HAIRYFN depends on the :FORMAT-CONTROL and :FORMAT-ARGUMENTS.
1696 ;;; Read all forms from INFO and compile them, with output to OBJECT.
1697 ;;; Return (VALUES ABORT-P WARNINGS-P FAILURE-P).
1735 ;; Dump the code coverage records into the fasl.
1744 list))
1745 nil
1746 nil)))
1753 nil))))
1754 ;; Some errors are sufficiently bewildering that we just fail
1755 ;; immediately, without trying to recover and compile more of
1756 ;; the input file.
1762 "~@<~@:_compilation aborted because of fatal error: ~2I~_~A~@:_~:>"
1767 ;;; Return a pathname for the named file. The file must exist.
1776 new
1792 ;;; Print some junk at the beginning and end of compilation.
1798 "preloading"
1804 file-info)
1806 :print-weekday nil
1813 won
1819 ;;; Open some files and call SUB-COMPILE-FILE. If something unwinds
1820 ;;; out of the compile, then abort the writing of the output file, so
1821 ;;; that we don't overwrite it with known garbage.
1824 &key
1826 ;; ANSI options
1828 ;; FIXME: ANSI doesn't seem to say anything about
1829 ;; *COMPILE-VERBOSE* and *COMPILE-PRINT* being rebound by this
1830 ;; function..
1835 ;; extensions
1839 #!+sb-doc
1840 "Compile INPUT-FILE, producing a corresponding fasl file and
1841 returning its filename.
1843 :PRINT
1844 If true, a message per non-macroexpanded top level form is printed
1845 to *STANDARD-OUTPUT*. Top level forms that whose subforms are
1846 processed as top level forms (eg. EVAL-WHEN, MACROLET, PROGN) receive
1847 no such message, but their subforms do.
1849 As an extension to ANSI, if :PRINT is :top-level-forms, a message
1850 per top level form after macroexpansion is printed to *STANDARD-OUTPUT*.
1851 For example, compiling an IN-PACKAGE form will result in a message about
1852 a top level SETQ in addition to the message about the IN-PACKAGE form'
1853 itself.
1855 Both forms of reporting obey the SB-EXT:*COMPILER-PRINT-VARIABLE-ALIST*.
1857 :BLOCK-COMPILE
1858 Though COMPILE-FILE accepts an additional :BLOCK-COMPILE
1859 argument, it is not currently supported. (non-standard)
1861 :TRACE-FILE
1862 If given, internal data structures are dumped to the specified
1863 file, or if a value of T is given, to a file of *.trace type
1864 derived from the input file name. (non-standard)
1866 :EMIT-CFASL
1867 (Experimental). If true, outputs the toplevel compile-time effects
1868 of this file into a separate .cfasl file."
1869 ;;; Block compilation is currently broken.
1870 #|
1871 "Also, as a workaround for vaguely-non-ANSI behavior, the
1872 :BLOCK-COMPILE argument is quasi-supported, to determine whether
1873 multiple functions are compiled together as a unit, resolving function
1874 references at compile time. NIL means that global function names are
1875 never resolved at compilation time. Currently NIL is the default
1877 of the ANSI spec allows this behavior under all circumstances, the
1878 compiler's runtime scales badly when it tries to do this for large
1879 files. If/when this performance problem is fixed, the block
1880 compilation default behavior will probably be made dependent on the
1881 SPEED and COMPILATION-SPEED optimization values, and the
1882 :BLOCK-COMPILE argument will probably become deprecated."
1883 |#
1918 default-trace-file-pathname
1920 default-trace-file-pathname))))
1954 ;; CLHS says that the first value is NIL if the "file could not
1955 ;; be created". We interpret this to mean "a valid fasl could not
1956 ;; be created" -- which can happen if the compilation is aborted
1957 ;; before the whole file has been processed, due to eg. a reader
1958 ;; error.
1960 ;; Hack around filesystem race condition...
1962 warnings-p
1963 failure-p)))
1964 \f
1965 ;;; a helper function for COMPILE-FILE-PATHNAME: the default for
1966 ;;; the OUTPUT-FILE argument
1967 ;;;
1968 ;;; ANSI: The defaults for the OUTPUT-FILE are taken from the pathname
1969 ;;; that results from merging the INPUT-FILE with the value of
1970 ;;; *DEFAULT-PATHNAME-DEFAULTS*, except that the type component should
1971 ;;; default to the appropriate implementation-defined default type for
1972 ;;; compiled files.
1976 retyped))
1978 ;;; KLUDGE: Part of the ANSI spec for this seems contradictory:
1979 ;;; If INPUT-FILE is a logical pathname and OUTPUT-FILE is unsupplied,
1980 ;;; the result is a logical pathname. If INPUT-FILE is a logical
1981 ;;; pathname, it is translated into a physical pathname as if by
1982 ;;; calling TRANSLATE-LOGICAL-PATHNAME.
1983 ;;; So I haven't really tried to make this precisely ANSI-compatible
1984 ;;; at the level of e.g. whether it returns logical pathname or a
1985 ;;; physical pathname. Patches to make it more correct are welcome.
1986 ;;; -- WHN 2000-12-09
1988 &key
1991 #!+sb-doc
1992 "Return a pathname describing what file COMPILE-FILE would write to given
1993 these arguments."
1997 \f
1998 ;;;; MAKE-LOAD-FORM stuff
2000 ;;; The entry point for MAKE-LOAD-FORM support. When IR1 conversion
2001 ;;; finds a constant structure, it invokes this to arrange for proper
2002 ;;; dumping. If it turns out that the constant has already been
2003 ;;; dumped, then we don't need to do anything.
2004 ;;;
2005 ;;; If the constant hasn't been dumped, then we check to see whether
2006 ;;; we are in the process of creating it. We detect this by
2007 ;;; maintaining the special *CONSTANTS-BEING-CREATED* as a list of all
2008 ;;; the constants we are in the process of creating. Actually, each
2009 ;;; entry is a list of the constant and any init forms that need to be
2010 ;;; processed on behalf of that constant.
2011 ;;;
2012 ;;; It's not necessarily an error for this to happen. If we are
2013 ;;; processing the init form for some object that showed up *after*
2014 ;;; the original reference to this constant, then we just need to
2015 ;;; defer the processing of that init form. To detect this, we
2016 ;;; maintain *CONSTANTS-CREATED-SINCE-LAST-INIT* as a list of the
2017 ;;; constants created since the last time we started processing an
2018 ;;; init form. If the constant passed to emit-make-load-form shows up
2019 ;;; in this list, then there is a circular chain through creation
2020 ;;; forms, which is an error.
2021 ;;;
2022 ;;; If there is some intervening init form, then we blow out of
2023 ;;; processing it by throwing to the tag PENDING-INIT. The value we
2024 ;;; throw is the entry from *CONSTANTS-BEING-CREATED*. This is so the
2025 ;;; offending init form can be tacked onto the init forms for the
2026 ;;; circular object.
2027 ;;;
2028 ;;; If the constant doesn't show up in *CONSTANTS-BEING-CREATED*, then
2029 ;;; we have to create it. We call MAKE-LOAD-FORM and check to see
2030 ;;; whether the creation form is the magic value
2031 ;;; :SB-JUST-DUMP-IT-NORMALLY. If it is, then we don't do anything. The
2032 ;;; dumper will eventually get its hands on the object and use the
2033 ;;; normal structure dumping noise on it.
2034 ;;;
2035 ;;; Otherwise, we bind *CONSTANTS-BEING-CREATED* and
2036 ;;; *CONSTANTS-CREATED-SINCE- LAST-INIT* and compile the creation form
2037 ;;; much the way LOAD-TIME-VALUE does. When this finishes, we tell the
2038 ;;; dumper to use that result instead whenever it sees this constant.
2039 ;;;
2040 ;;; Now we try to compile the init form. We bind
2041 ;;; *CONSTANTS-CREATED-SINCE-LAST-INIT* to NIL and compile the init
2042 ;;; form (and any init forms that were added because of circularity
2043 ;;; detection). If this works, great. If not, we add the init forms to
2044 ;;; the init forms for the object that caused the problems and let it
2045 ;;; deal with it.
2048 ;;; FIXME: Shouldn't these^ variables be unbound outside LET forms?
2053 ;; KLUDGE: This special hack is because I was too lazy
2054 ;; to rework DEF!STRUCT so that the MAKE-LOAD-FORM
2055 ;; function of LAYOUT returns nontrivial forms when
2056 ;; building the cross-compiler but :IGNORE-IT when
2057 ;; cross-compiling or running under the target Lisp. --
2058 ;; WHN 19990914
2065 ;; If this is a global constant reference, we can call SYMBOL-GLOBAL-VALUE
2066 ;; during LOAD as a fasl op, and not compile a lambda.
2074 #-sb-xc-host
2079 constant creation-form init-form))
2082 (:sb-just-dump-it-normally
2084 t)
2085 (:ignore-it
2086 nil)
2099 constant
2102 fasl)
2103 nil)
2105 constant)))
2111 collect form into forms
2114 nil)))
2118 nil)))))
2120 \f
2121 ;;;; Host compile time definitions
2122 #+sb-xc-host
2127 #+sb-xc-host