| blob | 3881946a36cd5dab589926e260ac3fe9faa98ef2 |
1 ;;;; the top level interfaces to the compiler
3 ;;;; This software is part of the SBCL system. See the README file for
4 ;;;; more information.
5 ;;;;
6 ;;;; This software is derived from the CMU CL system, which was
7 ;;;; written at Carnegie Mellon University and released into the
8 ;;;; public domain. The software is in the public domain and is
9 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
10 ;;;; files for more information.
17 ;;; *BLOCK-COMPILE-ARGUMENT* holds the original value of the :BLOCK-COMPILE
18 ;;; argument, which overrides any internal declarations.
33 "When this is true, the compiler prints to *STANDARD-OUTPUT* progress
34 information about the phases of compilation of each function. (This
38 "The defaulted pathname of the file currently being compiled, or NIL if not
41 "The TRUENAME of the file currently being compiled, or NIL if not
48 ;;; the SOURCE-INFO structure for the current compilation. This is
49 ;;; null globally to indicate that we aren't currently in any
50 ;;; identifiable compilation.
53 ;;; This is true if we are within a WITH-COMPILATION-UNIT form (which
54 ;;; normally causes nested uses to be no-ops).
57 ;;; Count of the number of compilation units dynamically enclosed by
58 ;;; the current active WITH-COMPILATION-UNIT that were unwound out of.
61 ;;; Mumble conditional on *COMPILE-PROGRESS*.
75 ;; Used during compilation to map code paths to the matching
76 ;; instrumentation conses.
78 ;; Used during compilation to keep track of with source paths have been
79 ;; instrumented in which blocks.
81 \f
82 ;;;; WITH-COMPILATION-UNIT and WITH-COMPILATION-VALUES
85 "Affects compilations that take place within its dynamic extent. It is
86 intended to be eg. wrapped around the compilation of all files in the same system.
88 Following options are defined:
90 :OVERRIDE Boolean-Form
91 One of the effects of this form is to delay undefined warnings until the
92 end of the form, instead of giving them at the end of each compilation.
93 If OVERRIDE is NIL (the default), then the outermost
94 WITH-COMPILATION-UNIT form grabs the undefined warnings. Specifying
95 OVERRIDE true causes that form to grab any enclosed warnings, even if it
96 is enclosed by another WITH-COMPILATION-UNIT.
98 :POLICY Optimize-Declaration-Form
99 Provides dynamic scoping for global compiler optimization qualities and
100 restrictions, limiting effects of subsequent OPTIMIZE proclamations and
101 calls to SB-EXT:RESTRICT-COMPILER-POLICY to the dynamic scope of BODY.
103 If OVERRIDE is false, specified POLICY is merged with current global
104 policy. If OVERRIDE is true, current global policy, including any
105 restrictions, is discarded in favor of the specified POLICY.
107 Supplying POLICY NIL is equivalent to the option not being supplied at
108 all, ie. dynamic scoping of policy does not take place.
110 This option is an SBCL-specific experimental extension: Interface
111 subject to change.
113 :SOURCE-NAMESTRING Namestring-Form
114 Attaches the value returned by the Namestring-Form to the internal
115 debug-source information as the namestring of the source file. Normally
116 the namestring of the input-file for COMPILE-FILE is used: this option
117 can be used to provide source-file information for functions compiled
118 using COMPILE, or to override the input-file of COMPILE-FILE.
120 If both an outer and an inner WITH-COMPILATION-UNIT provide a
121 SOURCE-NAMESTRING, the inner one takes precedence. Unaffected
122 by :OVERRIDE.
124 This is an SBCL-specific extension.
126 :SOURCE-PLIST Plist-Form
127 Attaches the value returned by the Plist-Form to internal debug-source
128 information of functions compiled in within the dynamic extent of BODY.
130 Primarily for use by development environments, in order to eg. associate
131 function definitions with editor-buffers. Can be accessed using
132 SB-INTROSPECT:DEFINITION-SOURCE-PLIST.
134 If an outer WITH-COMPILATION-UNIT form also provide a SOURCE-PLIST, it
135 is appended to the end of the provided SOURCE-PLIST. Unaffected
136 by :OVERRIDE.
138 This is an SBCL-specific extension.
140 Examples:
142 ;; Prevent proclamations from the file leaking, and restrict
143 ;; SAFETY to 3 -- otherwise uses the current global policy.
144 (with-compilation-unit (:policy '(optimize))
145 (restrict-compiler-policy 'safety 3)
148 ;; Using default policy instead of the current global one,
149 ;; except for DEBUG 3.
150 (with-compilation-unit (:policy '(optimize debug)
151 :override t)
154 ;; Same as if :POLICY had not been specified at all: SAFETY 3
155 ;; proclamation leaks out from WITH-COMPILATION-UNIT.
156 (with-compilation-unit (:policy nil)
157 (declaim (optimize safety))
159 "
175 ;; Inside another WITH-COMPILATION-UNIT, a WITH-COMPILATION-UNIT is
176 ;; ordinarily (unless OVERRIDE) basically a no-op.
207 ;;; Is NAME something that no conforming program can rely on
208 ;;; defining?
213 (:function
216 (:type
223 ;;; This is to be called at the end of a compilation unit. It signals
224 ;;; any residual warnings about unknown stuff, then prints the total
225 ;;; error counts. ABORT-P should be true when the compilation unit was
226 ;;; aborted by throwing out. ABORT-COUNT is the number of dynamically
227 ;;; enclosed nested compilation units that were aborted.
256 (:function
258 "~@<The function ~S is undefined, and its name is ~
259 reserved by ANSI CL so that even if it were ~
260 defined later, the code doing so would not be ~
262 (:type
265 "~@<Undefined type ~S. The name starts with ~S: ~
266 probably use of a quoted type name in a context ~
267 where the name is not evaluated.~:@>"
270 "~@<Undefined type ~S. Note that name ~S is ~
271 reserved by ANSI CL, so code defining a type with ~
272 that name would not be portable.~:@>" name
273 name))))
277 kind name)))
283 "~W more use~:P of undefined ~(~A~) ~S"
284 more kind name)
286 "~W more use~:P of undefined ~(~A~) ~S"
287 more kind name))))))))))
298 abort-p)
302 "~& Undefined ~(~A~)~p:~
303 ~% ~{~<~% ~1:;~S~>~^ ~}"
306 ~[~:;~:*~& caught ~W ERROR condition~:P~]~
307 ~[~:;~:*~& caught ~W WARNING condition~:P~]~
308 ~[~:;~:*~& caught ~W STYLE-WARNING condition~:P~]~
309 ~[~:;~:*~& printed ~W note~:P~]"
318 ;;; Evaluate BODY, then return (VALUES BODY-VALUE WARNINGS-P
319 ;;; FAILURE-P), where BODY-VALUE is the first value of the body, and
320 ;;; WARNINGS-P and FAILURE-P are as in CL:COMPILE or CL:COMPILE-FILE.
326 collect
339 ;;; THING is a kind of thing about which we'd like to issue a warning,
340 ;;; but showing at most one warning for a given set of <THING,FMT,ARGS>.
341 ;;; The compiler does a good job of making sure not to print repetitive
342 ;;; warnings for code that it compiles, but this solves a different problem.
343 ;;; Specifically, for a warning from PARSE-LAMBDA-LIST, there are three calls:
344 ;;; - once in the expander for defmacro itself, as it calls MAKE-MACRO-LAMBDA
345 ;;; which calls PARSE-LAMBDA-LIST. This is the toplevel form processing.
346 ;;; - again for :compile-toplevel, where the DS-BIND calls PARSE-LAMBDA-LIST.
347 ;;; If compiling in compile-toplevel, then *COMPILE-OBJECT* is a core object,
348 ;;; but if interpreting, then it is still a fasl.
349 ;;; - once for compiling to fasl. *COMPILE-OBJECT* is a fasl.
350 ;;; I'd have liked the data to be associated with the fasl, except that
351 ;;; as indicated above, the second line hides some information.
360 ;; THING is compared by EQ, FMT mostly by STRING=.
367 nil)
368 ;; If at least one is a FMT-CONTROL-PROXY
369 ;; the two should be either EQ or a
370 ;; mismatch.
375 ;; We don't want to walk into default values,
376 ;; e.g. (&optional (b #<insane-struct))
377 ;; because #<insane-struct> might be circular.
386 \f
387 ;;;; component compilation
390 "The upper limit on the number of times that we will consecutively do IR1
391 optimization that doesn't introduce any new code. A finite limit is
399 ;;; Repeatedly optimize COMPONENT until no further optimizations can
400 ;;; be found or we hit our iteration limit. When we hit the limit, we
401 ;;; clear the component and block REOPTIMIZE flags to discourage the
402 ;;; next optimization attempt from pounding on the same code.
410 reoptimized)
414 fastp nil
415 cleared-reanalyze t
437 reoptimized))
444 ;;; Iterate doing FIND-DFO until no new dead code is discovered.
455 t))
462 reoptimized)
464 again
474 ;; Constraint propagation did something but that
475 ;; information didn't lead to any new optimizations.
476 ;; Don't run constraint-propagate again.
495 ;; Do it once more for the transforms that will produce code
496 ;; that loses some information for further optimizations and
497 ;; it's better to insert it at the last moment.
498 ;; Such code shouldn't need constraint propagation, the slowest
499 ;; part, so avoid it.
502 constraint-propagate nil)
505 ;;; Do all the IR1 phases for a non-top-level component.
517 do
519 ;; Join the blocks that were generated by GENERATE-TYPE-CHECKS
520 ;; now that all the blocks have the same TYPE-CHECK attribute
526 #-immobile-code
530 #+immobile-code
534 #-sb-xc-host
542 :dynamic
546 #-sb-xc-host
569 ;; Assign BLOCK-NUMBER for any cleanup blocks introduced by
570 ;; stack analysis. There shouldn't be any unreachable code after
571 ;; control, so this won't delete anything.
577 ;; For on-demand recalculation of dominators, the previously
578 ;; computed results may be stale.
628 elsewhere-label fixup-notes alloc-points)
638 #-sb-xc-host
647 fun-table)))
660 fixup-notes alloc-points
661 object)))
663 ;; We're done, so don't bother keeping anything around.
668 ;;; Delete components with no external entry points before we try to
669 ;;; generate code. Unreachable closures can cause IR2 conversion to
670 ;;; puke on itself, since it is the reference to the closure which
671 ;;; normally causes the components to be combined.
695 ;; Record xref information before optimization. This way the
696 ;; stored xref data reflects the real source as closely as
697 ;; possible.
702 ;; KLUDGE: We should instead set COMPONENT-REOPTIMIZE to T
703 ;; whenever a REF gets deleted so that DFO-AS-NEEDED kicks in only
704 ;; when needed, and we don't need this call to do a final
705 ;; unreachable entry point scan.
714 #|
726 |#
743 \f
744 ;;;; clearing global data structures
745 ;;;;
746 ;;;; FIXME: Is it possible to get rid of this stuff, getting rid of
747 ;;;; global data structures entirely when possible and consing up the
748 ;;;; others from scratch instead of clearing and reusing them?
750 ;;; Clear the INFO in constants in the *IR1-NAMESPACE*, etc. In
751 ;;; addition to allowing stuff to be reclaimed, this is required for
752 ;;; correct assignment of constant offsets, since we need to assign a
753 ;;; new offset for each component. We don't clear the FUNCTIONAL-INFO
754 ;;; slots, since they are used to keep track of functions across
755 ;;; component boundaries.
768 ;;; Blow away the REFS for all global variables, and let COMPONENT
769 ;;; be recycled.
781 x))
786 ;; There can be more constants to blast when considering them by EQL rather
787 ;; than similarity. But it's totally OK to visit a #<CONSTANT> twice.
788 ;; Its refs will be scanned redundantly, which is harmless.
792 ;;; Clear the global hash tables held in IR1-NAMESPACE.
798 ;; FIXME: It would make sense to clear these tables on arm64 as
799 ;; well, but it relies on the constant for NIL to stay around in
800 ;; order to assign a wired TN to it. A possible fix is to give
801 ;; arm64 NULL-SC like on other platforms.
802 #-arm64
806 \f
807 ;;;; trace output
809 ;;; Print out some useful info about COMPONENT to STREAM.
830 \f
831 ;;; Leave this as NIL if you want modern, rational, correct, behavior,
832 ;;; or switch it to T for legacy (CLHS-specified) bullshit a la
833 ;;; "During a call to compile-file, *compile-file-pathname* is bound to the pathname
834 ;;; denoted by the first argument to compile-file, merged against the defaults"
835 ;;; The normal build sets it to T in make-target-2, despite that I think most people would
836 ;;; prefer the nonstandard behavior. The standard behavior makes stored pathnames all wrong
837 ;;; when files are physically moved. (Same problem as SBCL_HOME embedded into C pretty much)
840 ;;; Given a pathname, return a SOURCE-INFO structure.
844 ;; becomes *COMPILE-FILE-PATHNAME*
846 :external-format external-format
850 ;; LOAD-AS-SOURCE uses this.
854 ;; This T-L-P has been around since at least 2011.
855 ;; It's unclear why an LPN isn't good enough.
860 ;;; Return a SOURCE-INFO to describe the incremental compilation of FORM.
868 ;;; Walk up the SOURCE-INFO list until we either reach a SOURCE-INFO
869 ;;; with no parent (e.g., from a REPL evaluation) or until we reach a
870 ;;; SOURCE-INFO whose FILE-INFO denotes a file.
878 finfo))))
880 ;;; If STREAM is present, return it, otherwise open a stream to the
881 ;;; current file. There must be a current file.
882 ;;;
883 ;;; FIXME: This is probably an unnecessarily roundabout way to do
884 ;;; things now that we process a single file in COMPILE-FILE (unlike
885 ;;; the old CMU CL code, which accepted multiple files). Also, the old
886 ;;; comment said
887 ;;; When we open a new file, we also reset *PACKAGE* and policy.
888 ;;; This gives the effect of rebinding around each file.
889 ;;; which doesn't seem to be true now. Check to make sure that if
890 ;;; such rebinding is necessary, it's still done somewhere.
891 ;;; FIXME: We will want to have a way to process multiple files again
892 ;;; for the sake of block compilation.
902 :external-format external-format
903 ;; SBCL stream classes aren't available in the host
906 ;; If you don't want merged pathnames embedded in your build artifacts,
907 ;; then you surely don't want them in *COMPILE-FILE-PATHNAME* either.
908 ;; [And can't we just bind this to PATHNAME is all cases? If anything,
909 ;; it seems to me that asking the stream for its name is expressly backwards]
917 ;; This used to happen before opening the file, which
918 ;; inhibited lazy computation of the truename, and was a
919 ;; minor time-of-check-vs-time-of-use mistake. It doesn't
920 ;; seem worthwhile to pass the verbose bit down from C-F,
921 ;; however.
924 stream))))
926 ;;; Close the stream in INFO if it is open.
934 ;; Loop over forms read from INFO's stream, calling FUNCTION with each.
935 ;; CONDITION-NAME is signaled if there is a reader error, and should be
936 ;; a subtype of not-so-aptly-named INPUT-ERROR-IN-COMPILE-FILE.
944 ;; Return a form read from STREAM; or for EOF use the trick,
945 ;; popularized by Kent Pitman, of returning STREAM itself.
948 ;; Reset for a new toplevel form.
956 ;; We don't need to supply :POSITION here because
957 ;; READER-ERRORs already know their position in the file.
958 :condition condition
960 ;; ANSI, in its wisdom, says that READ should return END-OF-FILE
961 ;; (and that this is not a READER-ERROR) when it encounters end of
962 ;; file in the middle of something it's trying to read,
963 ;; making it unfortunately indistinguishable from legal EOF.
964 ;; Were it not for that, it would be more elegant to just
965 ;; handle one more condition in the HANDLER-CASE.
968 condition-name
969 :condition condition
970 ;; We need to supply :POSITION here because the END-OF-FILE
971 ;; condition doesn't carry the position that the user
972 ;; probably cares about, where the failed READ began.
973 :position
976 pos)
980 stream
985 :current-index
990 current-idx))
993 ;;; Loop over FORMS retrieved from INFO. Used by COMPILE-FILE and
994 ;;; LOAD when loading from a FILE-STREAM associated with a source
995 ;;; file. ON-ERROR is the name of a condition class that should
996 ;;; be signaled if anything goes wrong during a READ.
1005 ;;; Return the INDEX'th source form read from INFO and the position
1006 ;;; where it was read.
1012 \f
1013 ;;;; processing of top level forms
1015 ;;; This is called by top level form processing when we are ready to
1016 ;;; actually compile something. If (BLOCK-COMPILE *COMPILATION*) is T,
1017 ;;; then we still convert the form, but delay compilation, pushing the result
1018 ;;; on (TOPLEVEL-LAMBDAS *COMPILATION*) instead.
1019 ;;;
1020 ;;; The policy at this time becomes the default policy for compiling
1021 ;;; the form. Any enclosed PROCLAIMs will affect only subsequent
1022 ;;; forms.
1025 #+sb-xc-host
1028 ;; Don't bother to compile simple objects that just sit there.
1043 nil)))
1045 ;;; Macroexpand FORM in the current environment with an error handler.
1046 ;;; We only expand one level, so that we retain all the intervening
1047 ;;; forms in the source path. A compiler-macro takes precedence over
1048 ;;; an ordinary macro as specified in CLHS 3.2.3.1
1049 ;;; Note that this function is _only_ for processing of toplevel forms.
1050 ;;; Non-toplevel forms use IR1-CONVERT-FUNCTOID which considers compiler macros.
1063 condition))))
1066 ;;; Process a PROGN-like portion of a top level form. FORMS is a list of
1067 ;;; the forms, and PATH is the source path of the FORM they came out of.
1068 ;;; COMPILE-TIME-TOO is as in ANSI "3.2.3.1 Processing of Top Level Forms".
1074 ;;; Process a top level use of LOCALLY, or anything else (e.g.
1075 ;;; MACROLET) at top level which has declarations and ordinary forms.
1076 ;;; We parse declarations and then recursively process the body.
1081 ;; FIXME: VALUES declaration
1082 ;;
1083 ;; Binding *POLICY* is pretty much of a hack, since it
1084 ;; causes LOCALLY to "capture" enclosed proclamations. It
1085 ;; is necessary because CONVERT-AND-MAYBE-COMPILE uses the
1086 ;; value of *POLICY* as the policy. The need for this hack
1087 ;; is due to the quirk that there is no way to represent in
1088 ;; a POLICY that an optimize quality came from the default.
1089 ;;
1090 ;; FIXME: Ideally, something should be done so that DECLAIM
1091 ;; inside LOCALLY works OK. Failing that, at least we could
1092 ;; issue a warning instead of silently screwing up.
1093 ;; Here's how to fix this: a POLICY object can in fact represent
1094 ;; absence of qualitities. Whenever we rebind *POLICY* (here and
1095 ;; elsewhere), it should be bound to a policy that expresses no
1096 ;; qualities. Proclamations should update SYMBOL-GLOBAL-VALUE of
1097 ;; *POLICY*, which can be seen irrespective of dynamic bindings,
1098 ;; and declarations should update the lexical policy.
1099 ;; The POLICY macro can be amended to merge the dynamic *POLICY*
1100 ;; (or whatever it came from, like a LEXENV) with the global
1101 ;; *POLICY*. COERCE-TO-POLICY can do the merge, employing a 1-line
1102 ;; cache so that repeated calls for any two fixed policy objects
1103 ;; return the identical value (since policies are immutable).
1105 ;; This is probably also a hack
1107 ;; ditto
1111 ;;; Parse an EVAL-WHEN situations list, returning three flags,
1112 ;;; (VALUES COMPILE-TOPLEVEL LOAD-TOPLEVEL EXECUTE), indicating
1113 ;;; the types of situations present in the list.
1117 '(:compile-toplevel
1118 compile
1119 :load-toplevel
1120 load
1121 :execute
1122 eval)))
1127 deprecated-names)))
1129 situations)
1133 ;;; Print some noise about FORM if *COMPILE-PRINT* is true.
1142 ;;; Handle the evaluation the a :COMPILE-TOPLEVEL body during
1143 ;;; compilation. Normally just evaluate in the appropriate
1144 ;;; environment, but also compile if outputting a CFASL.
1154 ;; Macro policy is such a kludge. Most of the effect is conferred by
1155 ;; injecting declarations into any sexpr coming from MAKE-MACRO-LAMBDA.
1156 ;; But that's not enough - we need all code in EVAL-WHEN :COMPILE-TOPLEVEL
1157 ;; situations to run under the macro policy. This somewhat works by binding
1158 ;; *LEXENV*, but fails anywhere we use MAKE-NULL-LEXENV, which sees only
1159 ;; the policy in *POLICY* from the perspective of that lexenv.
1160 ;; So we have to change *POLICY* also, but without binding it, because
1161 ;; binding prevents toplevel DECLAIMs from taking effect. As a workaround,
1162 ;; we assign *POLICY* but restore the original qualities whose values
1163 ;; were present in the macro policy.
1164 ;; e.g:
1165 ;; - macro policy of (safety 3)
1166 ;; - global policy of (safety 0) and (store-coverage-data 3)
1167 ;; - some file wants to declaim (safety 1) (store-coverage-data 0)
1168 ;; So because the DECLAIM is an EVAL-WHEN :COMPILE-TOPLEVEL with a macro policy,
1169 ;; we would try to restore *POLICY* to (safety 0) (store-coverage-data 3)
1170 ;; immediately after eval'ing the DECLAIM, making it totally effectless.
1180 ;; There are other ways to do this. e.g.: only save a declaim if it contained
1181 ;; a quality names intersecting with the ones in macro policy; then don't
1182 ;; restore everything to the start sate, merely undo changes from macro-policy,
1183 ;; but keeping the changes that were expressed by toplevel forms.
1184 ;; This is easiest and I really don't care to think about it.
1191 ;;; Process a top level FORM with the specified source PATH.
1192 ;;; * If this is a magic top level form, then do stuff.
1193 ;;; * If this is a macro, then expand it.
1194 ;;; * Otherwise, just compile it.
1195 ;;;
1196 ;;; COMPILE-TIME-TOO is as defined in ANSI
1197 ;;; "3.2.3.1 Processing of Top Level Forms".
1208 path)
1218 ;; CT, LT, and E here are as in Figure 3-7 of ANSI
1219 ;; "3.2.3.1 Processing of Top Level Forms".
1228 magic
1234 magic
1259 hash-table)
1260 new))
1261 \f
1262 ;;;; load time value support
1263 ;;;;
1264 ;;;; (See EMIT-MAKE-LOAD-FORM.)
1266 ;;; Return T if we are currently producing a fasl file and hence
1267 ;;; constants need to be dumped carefully.
1272 ;;; Compile FORM and arrange for it to be called at load-time. Return
1273 ;;; the dumper handle and our best guess at the type of the object.
1274 ;;; TODO: We could use a bytecode compiler here to produce smaller
1275 ;;; code. Same goes for top level code.
1284 ;;; Compile the FORMS and arrange for them to be called (for effect,
1285 ;;; not value) at load time.
1290 ;;; Do the actual work of COMPILE-LOAD-TIME-VALUE or
1291 ;;; COMPILE-MAKE-LOAD-FORM-INIT-FORMS.
1293 ;; We want to force top level lambdas before any recursive IR1
1294 ;; namespacing happens. Therefore, we need to force here as well as
1295 ;; in EMIT-MAKE-LOAD-FORMS, since we could enter recursive IR1
1296 ;; namespacing through either function.
1302 lambda)))
1304 ;;; This is called by COMPILE-TOPLEVEL when it was passed T for
1305 ;;; LOAD-TIME-VALUE-P (which happens in COMPILE-LOAD-TIME-STUFF). We
1306 ;;; don't try to combine this component with anything else and frob
1307 ;;; the name. If not in a :TOPLEVEL component, then don't bother
1308 ;;; compiling, because it was merged with a run-time component.
1319 ;;; The entry point for MAKE-LOAD-FORM support. When IR1 conversion
1320 ;;; finds a constant structure, it invokes this to arrange for proper
1321 ;;; dumping. If it turns out that the constant has already been
1322 ;;; dumped, then we don't need to do anything.
1323 ;;;
1324 ;;; If the constant hasn't been dumped, then we check to see whether
1325 ;;; we are in the process of creating it. We detect this by
1326 ;;; maintaining the special *CONSTANTS-BEING-CREATED* as a list of all
1327 ;;; the constants we are in the process of creating. Actually, each
1328 ;;; entry is a list of the constant and any init forms that need to be
1329 ;;; processed on behalf of that constant.
1330 ;;;
1331 ;;; It's not necessarily an error for this to happen. If we are
1332 ;;; processing the init form for some object that showed up *after*
1333 ;;; the original reference to this constant, then we just need to
1334 ;;; defer the processing of that init form. To detect this, we
1335 ;;; maintain *CONSTANTS-CREATED-SINCE-LAST-INIT* as a list of the
1336 ;;; constants created since the last time we started processing an
1337 ;;; init form. If the constant passed to emit-make-load-form shows up
1338 ;;; in this list, then there is a circular chain through creation
1339 ;;; forms, which is an error.
1340 ;;;
1341 ;;; If there is some intervening init form, then we blow out of
1342 ;;; processing it by throwing to the tag PENDING-INIT. The value we
1343 ;;; throw is the entry from *CONSTANTS-BEING-CREATED*. This is so the
1344 ;;; offending init form can be tacked onto the init forms for the
1345 ;;; circular object.
1346 ;;;
1347 ;;; If the constant doesn't show up in *CONSTANTS-BEING-CREATED*, then
1348 ;;; we have to create it. We call MAKE-LOAD-FORM and check if the
1349 ;;; result comes from MAKE-LOAD-FORM-SAVING-SLOTS, and if so we don't
1350 ;;; do anything. The dumper will eventually get its hands on the
1351 ;;; object and use the normal structure dumping noise on it.
1352 ;;;
1353 ;;; Otherwise, we bind *CONSTANTS-BEING-CREATED* and
1354 ;;; *CONSTANTS-CREATED-SINCE- LAST-INIT* and compile the creation form
1355 ;;; much the way LOAD-TIME-VALUE does. When this finishes, we tell the
1356 ;;; dumper to use that result instead whenever it sees this constant.
1357 ;;;
1358 ;;; Now we try to compile the init form. We bind
1359 ;;; *CONSTANTS-CREATED-SINCE-LAST-INIT* to NIL and compile the init
1360 ;;; form (and any init forms that were added because of circularity
1361 ;;; detection). If this works, great. If not, we add the init forms to
1362 ;;; the init forms for the object that caused the problems and let it
1363 ;;; deal with it.
1384 ;; Used mainly as an optimization to avoid dumping internal
1385 ;; compiler data structures (see :IGNORE-IT), and to avoid
1386 ;; unnecessary top level lambda forcing.
1390 nil)
1392 ;; MAKE-LOAD-FORM-SAVING-SLOTS on the cross-compiler needs
1393 ;; the type to be defined for the target.
1394 #+sb-xc-host
1403 t)
1415 t)))))
1420 ;; Allow dumping objects that can't be printed
1421 ;; Non-invocation of PRINT-OBJECT is tested by 'mlf.impure-cload.lisp'.
1423 #-sb-xc-host
1436 constant
1438 fasl)
1439 nil)
1441 constant)))
1447 collect form into forms
1449 nil)))
1453 nil)))))
1455 \f
1456 ;;;; COMPILE-FILE
1458 ;;; The maximum number of top-level lambdas we put in a single top-level
1459 ;;; component.
1467 #-sb-xc-host
1471 ;;; Add LAMBDAS to the pending lambdas. If this leaves more than
1472 ;;; TOP-LEVEL-LAMBDA-MAX lambdas in the list, or if FORCE-P is true,
1473 ;;; then smash the lambdas into a single component, compile it, and
1474 ;;; arrange for the resulting function to be called.
1483 force-p
1494 ;;; Compile top level code and call the top level lambdas. We pick off
1495 ;;; top level lambdas in non-top-level components here, calling
1496 ;;; SUB-c-t-l-l on each subsequence of normal top level lambdas.
1505 lambdas
1506 ;; this used to read ":start start", but
1507 ;; start can be greater than len, which
1508 ;; is an error according to ANSI - CSR,
1509 ;; 2002-04-25
1511 len)))
1523 ;;; Compile LAMBDAS (a list of CLAMBDAs for top level forms) into the
1524 ;;; object file. We loop doing local call analysis until it converges,
1525 ;;; since a single pass might miss something due to components being
1526 ;;; joined by let conversion.
1557 ;;; Actually compile any stuff that has been queued up for block
1558 ;;; compilation.
1579 ;; Is this right? I would think that if lexenv is null
1580 ;; we should look at *HANDLED-CONDITIONS*.
1604 ;; WOULD-MUFFLE-P is called (incorrectly) only by NOTE-UNDEFINED-REFERENCE.
1605 ;; It is not wrong per se, but as used, it is wrong, making it nearly
1606 ;; impossible to muffle a subset of undefind warnings whose NAME and KIND
1607 ;; slots match specific things tested by a user-defined predicate.
1608 ;; Attempting to do that might muffle everything, depending on how your
1609 ;; predicate responds to a vanilla WARNING. Consider e.g.
1610 ;; (AND WARNING (NOT (SATISFIES HAIRYFN)))
1611 ;; where HAIRYFN depends on the :FORMAT-CONTROL and :FORMAT-ARGUMENTS.
1617 ;;; Read all forms from INFO and compile them, with output to
1618 ;;; *COMPILE-OBJECT*. Return (VALUES ABORT-P WARNINGS-P FAILURE-P).
1633 ;; Whether to emit msan unpoisoning code depends on the runtime
1634 ;; value of the feature, not "#+msan", because we can use the target
1635 ;; compiler to compile code for itself which isn't sanitized,
1636 ;; *or* code for another image which is sanitized.
1637 ;; And we can also cross-compile assuming msan.
1675 #-sb-xc-host
1678 ;; FIXME: dump/restore "linkage" information, produce deferred warnings
1679 ;; (sb-fasl::dump-emitted-full-calls (emitted-full-calls *compilation*)
1680 ;; *compile-object*)
1684 ;; Dump the code coverage records into the fasl.
1687 collect k)
1689 nil)))
1690 ;; Some errors are sufficiently bewildering that we just fail
1691 ;; immediately, without trying to recover and compile more of
1692 ;; the input file.
1698 "~@<~@:_compilation aborted because of fatal error: ~2I~_~A~@:_~:>"
1703 ;;; Return a pathname for the named file. The file must exist.
1712 new
1728 ;;; Print some junk at the beginning and end of compilation.
1732 #+sb-xc-host
1736 #-sb-xc-host
1742 :print-weekday nil
1749 won
1768 nsec-diff))
1771 ;; FIXME: should we define #'(CAS SYMBOL-GLOBAL-VALUE) ?
1772 ;; Probably want to get it working everywhere first.
1775 #-x86-64
1777 #+x86-64
1781 ;;; Open some files and call SUB-COMPILE-FILE. If something unwinds
1782 ;;; out of the compile, then abort the writing of the output file, so
1783 ;;; that we don't overwrite it with known garbage.
1786 &key
1788 ;; ANSI options
1790 ;; We rebind the specials despite such behavior not being mentioned
1791 ;; in CLHS. Several other lisp implementations do this as well.
1796 ;; extensions
1803 "Compile INPUT-FILE, producing a corresponding fasl file and
1804 returning its filename.
1806 :OUTPUT-FILE
1807 The name of the FASL to output, NIL for none, T for the default.
1808 (Note the difference between the treatment of NIL :OUTPUT-FILE
1809 here and in COMPILE-FILE-PATHNAME.) The returned pathname of the
1810 output file may differ from the pathname of the :OUTPUT-FILE
1811 parameter, e.g. when the latter is a designator for a directory.
1813 :VERBOSE
1814 If true, information indicating what file is being compiled is printed
1815 to *STANDARD-OUTPUT*.
1817 :PRINT
1818 If true, each top level form in the file is printed to *STANDARD-OUTPUT*.
1820 :EXTERNAL-FORMAT
1821 The external format to use when opening the source file.
1823 :BLOCK-COMPILE {NIL | :SPECIFIED | T}
1824 Determines whether multiple functions are compiled together as a unit,
1825 resolving function references at compile time. NIL means that global
1826 function names are never resolved at compilation time. :SPECIFIED means
1827 that names are resolved at compile-time when convenient (as in a
1828 self-recursive call), but the compiler doesn't combine top-level DEFUNs.
1829 With :SPECIFIED, an explicit START-BLOCK declaration will enable block
1830 compilation. A value of T indicates that all forms in the file(s) should
1831 be compiled as a unit. The default is the value of
1832 SB-EXT:*BLOCK-COMPILE-DEFAULT*, which is initially NIL.
1834 :ENTRY-POINTS
1835 This specifies a list of function names for functions in the file(s) that
1836 must be given global definitions. This only applies to block
1837 compilation, and is useful mainly when :BLOCK-COMPILE T is specified on a
1838 file that lacks START-BLOCK declarations. If the value is NIL (the
1839 default) then all functions will be globally defined.
1841 :TRACE-FILE
1842 If given, internal data structures are dumped to the specified
1843 file, or if a value of T is given, to a file of *.trace type
1844 derived from the input file name. (non-standard)
1846 :EMIT-CFASL
1847 (Experimental). If true, outputs the toplevel compile-time effects
1848 of this file into a separate .cfasl file."
1868 ;; To avoid passing "" as OUTPUT-FILE when unsupplied, we exploit the fact
1869 ;; that COMPILE-FILE-PATHNAME allows random &KEY args.
1880 trace-file
1895 ;; There was an assignment here
1896 ;; (setq fasl-pathname (pathname (fasl-output-stream fasl-output)))
1897 ;; which seems pretty bogus, because we've computed the fasl-pathname,
1898 ;; and should return exactly what was computed so that it 100% agrees
1899 ;; with what COMPILE-FILE-PATHNAME said we would write into.
1900 ;; A distorted variation of the name coming from the stream is just wrong,
1901 ;; because do not support versioned pathnames.
1913 ;; Don't nuke stdout if you use :trace-file *standard-output*
1919 ;; CLHS says that the first value is NIL if the "file could not
1920 ;; be created". We interpret this to mean "a valid fasl could not
1921 ;; be created" -- which can happen if the compilation is aborted
1922 ;; before the whole file has been processed, due to eg. a reader
1923 ;; error.
1925 ;; Again, more bogosity. Why do PROBE-FILE here
1926 ;; when it achieves nothing other than to potentially disagree
1927 ;; with what COMPILE-FILE-PATHNAME returned.
1928 ;; I would guess that the intent of the spec was to not return
1929 ;; pathnames with a wild version component, but it never anticipated
1930 ;; that content-addressable storage would be a thing.
1931 ;; Unfortunately there's no way to give lossless information here
1932 ;; while remaining ANSI-compliant. So let's repurpose the secret
1933 ;; *MERGE-PATHNAMES* option to return pathnames that don't suck.
1935 output-file-pathname))
1936 warnings-p
1937 failure-p)))
1938 \f
1939 ;;; KLUDGE: Part of the ANSI spec for this seems contradictory:
1940 ;;; If INPUT-FILE is a logical pathname and OUTPUT-FILE is unsupplied,
1941 ;;; the result is a logical pathname. If INPUT-FILE is a logical
1942 ;;; pathname, it is translated into a physical pathname as if by
1943 ;;; calling TRANSLATE-LOGICAL-PATHNAME.
1944 ;;; So I haven't really tried to make this precisely ANSI-compatible
1945 ;;; at the level of e.g. whether it returns logical pathname or a
1946 ;;; physical pathname. Patches to make it more correct are welcome.
1947 ;;; -- WHN 2000-12-09
1948 ;;;
1949 ;;; Issues of logical-pathname handling aside, I checked some other lisps
1950 ;;; to see what they do with the following two examples:
1951 ;;; (COMPILE-FILE "a/b/file.lisp :output-file "x/y/z/")
1952 ;;; (COMPILE-FILE "a/b/file.lisp :output-file "x/y/out")
1953 ;;; and it turns out that they don't implement the spirit of the law,
1954 ;;; forget about the letter of the law. The spirit (intent) is that regardless
1955 ;;; of how pathnames are handled, COMPILE-FILE-PATHNAME should tell you exactly
1956 ;;; what pathname the compiler would write into given the input and output to
1957 ;;; COMPILE-FILE. But they can't even do that much correctly.
1958 ;;; So forget about how merging "should" work - it's a crap shoot at best.
1960 ;;; Clozure 1.10-r16196
1961 ;;; -------------------
1962 ;;; ? (COMPILE-FILE-PATHNAME "a/b/file.lisp" :output-file #p"x/y/z/")
1963 ;;; => #P"a/b/x/y/z/file.lx64fsl" ; ok, so it thinks it merges input and output dirs
1964 ;;; let's confirm by actually compiling:
1965 ;;; ? (COMPILE-FILE "a/b/file.lisp" :output-file #p"x/y/z/")
1966 ;;; #P"/tmp/sbcl/x/y/z/file.lx64fsl" ; no, it didn't actually. it's what I want though
1967 ;;;
1968 ;;; ECL 16.1.3
1969 ;;; ----------
1970 ;;; (compile-file-pathname "a/b/file.lisp" :output-file #p"x/y/z/")
1971 ;;; #P"x/y/z/" ; ok, maybe it will do additional defaulting to get the name and type?
1972 ;;; (compile-file "a/b/file.lisp" :output-file #p"x/y/z/")
1973 ;;; Internal error:
1974 ;;; ** Pathname without a physical namestring:
1975 ;;; Nope, it won't default them. However:
1976 ;;; (compile-file "a/b/file.lisp" :output-file #p"x/y/z/out")
1977 ;;; => #P"/tmp/sbcl/x/y/z/out"
1978 ;;; so it worked, but it failed to default the file type to '.fas'
1979 ;;; which it would have if nothing were specified.
1980 ;;;
1981 ;;; ABCL 1.7.1
1982 ;;; ----------
1983 ;;; (compile-file-pathname "a/b/file.lisp" :output-file #p"x/y/z/")
1984 ;;; #P"/tmp/sbcl/a/b/x/y/z/file.lisp" ; OK, so it says it merged input + output dirs
1985 ;;; but it didn't stick on a pathname-type. However
1986 ;;; (compile-file "a/b/file.lisp" :output-file #p"x/y/z/")
1987 ;;; ; Compiling /tmp/sbcl/a/b/file.lisp ...
1988 ;;; #<THREAD "interpreter" {E2B80EB}>: Debugger invoked on condition of type SIMPLE-ERROR
1989 ;;; Pathname has no namestring:
1990 ;;; And now:
1991 ;;; (compile-file "a/b/file.lisp" :output-file #p"x/y/z/out.abcl")
1992 ;;; => #P"/tmp/sbcl/x/y/z/out.abcl" ; so it *didn't* actually merge dirs, which is fine
1993 ;;;
1994 ;;; But we try our best to give somewhat understandable semantics:
1995 ;;; * strongly prefer that all fasls have a pathname-type
1996 ;;; whether or not the output was specified. However, if you are sadistic
1997 ;;; (and/or enjoy being confusing to others), then :OUTPUT-FILE is permitted
1998 ;;; to have :UNSPECIFIC as the type, and it will lack the '.fasl' suffix.
1999 ;;; * we can accept just a directory for the output (a namestring ending in "/"
2000 ;;; on Unix) and will take the pathname-name from the input
2001 ;;; * we will never merge directories from the input to output
2002 ;;;
2003 ;;; It is unclear what should happen with
2004 ;;; (compile-file "sys:contrib;foo.lisp" :output-file "obj")
2005 ;;; Is "obj" on the logical host or the physical host?
2009 "Return a pathname describing what file COMPILE-FILE would write to given
2010 these arguments."
2011 ;; ANSI: The defaults for the OUTPUT-FILE are taken from the pathname
2012 ;; that results from merging the INPUT-FILE with the value of
2013 ;; *DEFAULT-PATHNAME-DEFAULTS*, except that the type component should
2014 ;; default to the appropriate implementation-defined default type for
2015 ;; compiled files.
2020 input output)))
2021 ;; Merging *D-P-D* here is ridiculous, because every pathname is eventually
2022 ;; merged against it.
2023 ;; Users can set it to #P"" around calling this to obtain a lossless answer.
2026 ;; :unspecific is left alone, "as if the field were 'filled'"
2027 ;; (http://www.lispworks.com/documentation/HyperSpec/Body/19_bbbca.htm)
2028 ;; which makes little to zero sense at all for the PATHNAME-NAME
2029 ;; of a fasl file, but is allowable for its PATHNAME-TYPE.
2032 default)
2034 specified))))
2040 \f
2041 ;;; FIXME: find a better place for this.
2045 ;; Compiling to fasl considers a symbol always-bound if its
2046 ;; :always-bound info value is now T or will eventually be T.