| blob | c5e1a7a938f7fc47095444c7e088edf45e7fee48 |
1 ;;;; This file provides a functional interface to global information
2 ;;;; about named things in the system. Information is considered to be
3 ;;;; global if it must persist between invocations of the compiler. The
4 ;;;; use of a functional interface eliminates the need for the compiler
5 ;;;; to worry about the actual representation. This is important, since
6 ;;;; the information may well have several representations.
7 ;;;;
8 ;;;; The database contains arbitrary Lisp values, addressed by a
9 ;;;; combination of Name, Class and Type. The Name is a EQUAL-thing
10 ;;;; which is the name of the thing we are recording information
11 ;;;; about. Class is the kind of object involved. Typical classes are
12 ;;;; :FUNCTION, :VARIABLE, :TYPE, ... A Type names a particular piece
13 ;;;; of information within a given class. Class and Type are keywords,
14 ;;;; and are compared with EQ.
16 ;;;; This software is part of the SBCL system. See the README file for
17 ;;;; more information.
18 ;;;;
19 ;;;; This software is derived from the CMU CL system, which was
20 ;;;; written at Carnegie Mellon University and released into the
21 ;;;; public domain. The software is in the public domain and is
22 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
23 ;;;; files for more information.
30 ;;; The DEFVAR for this appears later.
31 ;;; FIXME: centralize
34 ;;; This is sorta semantically equivalent to SXHASH, but optimized for
35 ;;; legal function names.
36 ;;;
37 ;;; Why optimize? We want to avoid the fully-general TYPECASE in ordinary
38 ;;; SXHASH, because
39 ;;; 1. This hash function has to run when we're initializing the globaldb,
40 ;;; so it has to run before the type system is initialized, and it's
41 ;;; easier to make it do this if we don't try to do a general TYPECASE.
42 ;;; 2. This function is in a potential bottleneck for the compiler,
43 ;;; and avoiding the general TYPECASE lets us improve performance
44 ;;; because
45 ;;; 2a. the general TYPECASE is intrinsically slow, and
46 ;;; 2b. the general TYPECASE is too big for us to easily afford
47 ;;; to inline it, so it brings with it a full function call.
48 ;;;
49 ;;; Why not specialize instead of optimize? (I.e. why fall through to
50 ;;; general SXHASH as a last resort?) Because the INFO database is used
51 ;;; to hold all manner of things, e.g. (INFO :TYPE :BUILTIN ..)
52 ;;; which is called on values like (UNSIGNED-BYTE 29). Falling through
53 ;;; to SXHASH lets us support all manner of things (as long as they
54 ;;; aren't used too early in cold boot for SXHASH to run).
64 ;; We need to declare the type of the value we're feeding to
65 ;; SXHASH so that the DEFTRANSFORM on symbols kicks in.
71 ;;; Given any non-negative integer, return a prime number >= to it.
72 ;;;
73 ;;; FIXME: This logic should be shared with ALMOST-PRIMIFY in
74 ;;; hash-table.lisp. Perhaps the merged logic should be
75 ;;; PRIMIFY-HASH-TABLE-SIZE, implemented as a lookup table of primes
76 ;;; after integral powers of two:
77 ;;; #(17 37 67 131 ..)
78 ;;; (Or, if that's too coarse, after half-integral powers of two.) By
79 ;;; thus getting rid of any need for primality testing at runtime, we
80 ;;; could punt POSITIVE-PRIMEP, too.
85 \f
86 ;;;; info classes, info types, and type numbers, part I: what's needed
87 ;;;; not only at compile time but also at run time
89 ;;;; Note: This section is a blast from the past, a little trip down
90 ;;;; memory lane to revisit the weird host/target interactions of the
91 ;;;; CMU CL build process. Because of the way that the cross-compiler
92 ;;;; and target compiler share stuff here, if you change anything in
93 ;;;; here, you'd be well-advised to nuke all your fasl files and
94 ;;;; restart compilation from the very beginning of the bootstrap
95 ;;;; process.
97 ;;; At run time, we represent the type of info that we want by a small
98 ;;; non-negative integer.
103 ;;; Why do we suppress the :COMPILE-TOPLEVEL situation here when we're
104 ;;; running the cross-compiler? The cross-compiler (which was built
105 ;;; from these sources) has its version of these data and functions
106 ;;; defined in the same places we'd be defining into. We're happy with
107 ;;; its version, since it was compiled from the same sources, so
108 ;;; there's no point in overwriting its nice compiled version of this
109 ;;; stuff with our interpreted version. (And any time we're *not*
110 ;;; happy with its version, perhaps because we've been editing the
111 ;;; sources partway through bootstrapping, tch tch, overwriting its
112 ;;; version with our version would be unlikely to help, because that
113 ;;; would make the cross-compiler very confused.)
118 #-no-ansi-print-object
123 ;; name of this class
125 ;; list of Type-Info structures for each type in this class
128 ;;; a map from type numbers to TYPE-INFO objects. There is one type
129 ;;; number for each defined CLASS/TYPE pair.
130 ;;;
131 ;;; We build its value at build-the-cross-compiler time (with calls to
132 ;;; DEFINE-INFO-TYPE), then generate code to recreate the compile time
133 ;;; value, and arrange for that code to be called in cold load.
134 ;;; KLUDGE: We don't try to reset its value when cross-compiling the
135 ;;; compiler, since that creates too many bootstrapping problems,
136 ;;; instead just reusing the built-in-the-cross-compiler version,
137 ;;; which is theoretically a little bit ugly but pretty safe in
138 ;;; practice because the cross-compiler is as close to the target
139 ;;; compiler as we can make it, i.e. identical in most ways, including
140 ;;; this one. -- WHN 2001-08-19
149 #-no-ansi-print-object
153 "~S ~S, Number = ~W"
158 ;; the name of this type
160 ;; this type's class
162 ;; a number that uniquely identifies this type (and implicitly its class)
164 ;; a type specifier which info of this type must satisfy
166 ;; a function called when there is no information of this type
168 ;; called by (SETF INFO) before calling SET-INFO-VALUE
171 ;;; a map from class names to CLASS-INFO structures
172 ;;;
173 ;;; We build the value for this at compile time (with calls to
174 ;;; DEFINE-INFO-CLASS), then generate code to recreate the compile time
175 ;;; value, and arrange for that code to be called in cold load.
176 ;;; KLUDGE: Just as for *INFO-TYPES*, we don't try to rebuild this
177 ;;; when cross-compiling, but instead just reuse the cross-compiler's
178 ;;; version for the target compiler. -- WHN 2001-08-19
185 ;;; If NAME is the name of a type in CLASS, then return the TYPE-INFO,
186 ;;; otherwise NIL.
193 ;;; Return the info structure for an info class or type, or die trying.
220 \f
221 ;;;; info classes, info types, and type numbers, part II: what's
222 ;;;; needed only at compile time, not at run time
224 ;;; FIXME: Perhaps this stuff (the definition of DEFINE-INFO-CLASS
225 ;;; and the calls to it) could/should go in a separate file,
226 ;;; perhaps info-classes.lisp?
230 ;;; Set up the data structures to support an info class.
231 ;;;
232 ;;; comment from CMU CL:
233 ;;; We make sure that the class exists at compile time so that
234 ;;; macros can use it, but we don't actually store the init function
235 ;;; until load time so that we don't break the running compiler.
236 ;;; KLUDGE: I don't think that's the way it is any more, but I haven't
237 ;;; looked into it enough to write a better comment. -- WHN 2001-03-06
238 (#+sb-xc-host defmacro
243 ;; (We don't need to evaluate this at load time, compile time is
244 ;; enough. There's special logic elsewhere which deals with cold
245 ;; load initialization by inspecting the info class data
246 ;; structures at compile time and generating code to recreate
247 ;; those data structures.)
253 ;;; Find a type number not already in use by looking for a null entry
254 ;;; in *INFO-TYPES*.
259 ;;; a list of forms for initializing the DEFAULT slots of TYPE-INFO
260 ;;; objects, accumulated during compilation and eventually converted
261 ;;; into a function to be called at cold load time after the
262 ;;; appropriate TYPE-INFO objects have been created
263 ;;;
264 ;;; Note: This is quite similar to the !COLD-INIT-FORMS machinery, but
265 ;;; we can't conveniently use the ordinary !COLD-INIT-FORMS machinery
266 ;;; here. The problem is that the natural order in which the
267 ;;; default-slot-initialization forms are generated relative to the
268 ;;; order in which the TYPE-INFO-creation forms are generated doesn't
269 ;;; match the relative order in which the forms need to be executed at
270 ;;; cold load time.
273 ;;; Define a new type of global information for CLASS. TYPE is the
274 ;;; name of the type, DEFAULT is the value for that type when it
275 ;;; hasn't been set, and TYPE-SPEC is a type specifier which values of
276 ;;; the type must satisfy. The default expression is evaluated each
277 ;;; time the information is needed, with NAME bound to the name for
278 ;;; which the information is being looked up.
279 ;;;
280 ;;; The main thing we do is determine the type's number. We need to do
281 ;;; this at macroexpansion time, since both the COMPILE and LOAD time
282 ;;; calls to %DEFINE-INFO-TYPE must use the same type number.
283 (#+sb-xc-host defmacro
289 default)
293 ;; At compile time, ensure that the type number exists. It will
294 ;; need to be forced to exist at cold load time, too, but
295 ;; that's not handled here; it's handled by later code which
296 ;; looks at the compile time state and generates code to
297 ;; replicate it at cold load time.
304 :class class-info
308 ;; Arrange for TYPE-INFO-DEFAULT and TYPE-INFO-TYPE to be set
309 ;; at cold load time. (They can't very well be set at
310 ;; cross-compile time, since they differ between the
311 ;; cross-compiler and the target. The DEFAULT slot values
312 ;; differ because they're compiled closures, and the TYPE slot
313 ;; values differ in the use of SB!XC symbols instead of CL
314 ;; symbols.)
319 ;; FIXME: This code is sort of nasty. It would
320 ;; be cleaner if DEFAULT accepted a real
321 ;; function, instead of accepting a statement
322 ;; which will be turned into a lambda assuming
323 ;; that the argument name is NAME. It might
324 ;; even be more microefficient, too, since many
325 ;; DEFAULTs could be implemented as (CONSTANTLY
326 ;; NIL) instead of full-blown (LAMBDA (X) NIL).
335 \f
336 ;;;; generic info environments
340 ;; some string describing what is in this environment, for
341 ;; printing/debugging purposes only
346 \f
347 ;;;; generic interfaces
349 ;;; FIXME: used only in this file, needn't be in runtime
353 #!+sb-doc
354 "DO-INFO (Env &Key Name Class Type Value) Form*
355 Iterate over all the values stored in the Info-Env Env. Name is bound to
356 the entry's name, Class and Type are bound to the class and type
357 (represented as keywords), and Value is bound to the entry's value."
364 n-env body)))))
368 ;;; Return code to iterate over a compact info environment.
370 n-env body)
400 ,@body
402 compact-info-entry-last))
405 ;;; Return code to iterate over a volatile info environment.
407 n-env body)
431 \f
433 ;;;; compact info environments
435 ;;; The upper limit on the size of the ENTRIES vector in a COMPACT-INFO-ENV.
436 ;;;
437 ;;; "Why (U-B 28)?", you might wonder. Originally this was (U-B 16),
438 ;;; presumably to ensure that the arrays of :ELEMENT-TYPE
439 ;;; COMPACT-INFO-ENTRIES-INDEX could use a more space-efficient representation.
440 ;;; It turns out that a environment of of only 65536 entries is insufficient in
441 ;;; the modern world (see message from Cyrus Harmon to sbcl-devel, "Subject:
442 ;;; purify failure when compact-info-env-entries-bits is too small"). Using
443 ;;; (U-B 28) instead of (U-B 29) is to avoid the need for bignum overflow
444 ;;; checks, a probably pointless micro-optimization. Hardcoding the amount of
445 ;;; bits instead of deriving it from SB!VM::N-WORD-BITS is done to allow
446 ;;; use of a more efficient array representation on 64-bit platforms.
447 ;;; -- JES, 2005-04-06
451 ;;; the type of the values in COMPACT-INFO-ENTRIES-INFO
454 ;;; This is an open hashtable with rehashing. Since modification is
455 ;;; not allowed, we don't have to worry about deleted entries. We
456 ;;; indirect through a parallel vector to find the index in the
457 ;;; ENTRIES at which the entries for a given name starts.
461 ;; hashtable of the names in this environment. If a bucket is
462 ;; unused, it is 0.
464 ;; an indirection vector parallel to TABLE, translating indices in
465 ;; TABLE to the start of the ENTRIES for that name. Unused entries
466 ;; are undefined.
468 ;; a vector contining in contiguous ranges the values of for all the
469 ;; types of info for each name.
471 ;; a vector parallel to ENTRIES, indicating the type number for the
472 ;; value stored in that location and whether this location is the
473 ;; last type of info stored for this name. The type number is in the
474 ;; low TYPE-NUMBER-BITS bits, and the next bit is set if this is the
475 ;; last entry.
481 ;;; Return the value of the type corresponding to NUMBER for the
482 ;;; index INDEX in ENV.
494 t)))
499 ;;; Look up NAME in the compact environment ENV. HASH is the
500 ;;; GLOBALDB-SXHASHOID of NAME.
513 ;; same as (MOD NEW LEN), but faster.
516 new))))
523 env
524 number
530 ;;; the exact density (modulo rounding) of the hashtable in a compact
531 ;;; info environment in names/bucket
534 ;;; Return a new compact info environment that holds the same
535 ;;; information as ENV.
542 ;; Iterate over the environment once to find out how many names
543 ;; and entries it has, then build the result. This code assumes
544 ;; that all the entries for a name well be iterated over
545 ;; contiguously, which holds true for the implementation of
546 ;; iteration over both kinds of environments.
566 ;; Now that we know how big the environment is, we can build
567 ;; a table to represent it.
568 ;;
569 ;; When building the table, we sort the entries by pointer
570 ;; comparison in an attempt to preserve any VM locality present
571 ;; in the original load order, rather than randomizing with the
572 ;; original hash function.
576 compact-info-environment-density)
586 ;; (This MAKE-FIXNUM hack implements
587 ;; pointer comparison, as explained above.)
611 compact-info-entry-last)))
623 compact-info-entry-last)))
627 :table table
628 :index index
629 :entries entries
631 \f
632 ;;;; volatile environments
634 ;;; This is a closed hashtable, with the bucket being computed by
635 ;;; taking the GLOBALDB-SXHASHOID of the NAME modulo the table size.
638 ;; vector of alists of alists of the form:
639 ;; ((Name . ((Type-Number . Value) ...) ...)
641 ;; the number of distinct names currently in this table. Each name
642 ;; may have multiple entries, since there can be many types of info.
644 ;; the number of names at which we should grow the table and rehash
647 ;;; Just like COMPACT-INFO-LOOKUP, only do it on a volatile environment.
665 ;;; Given a volatile environment ENV, bind TABLE-VAR the environment's table
666 ;;; and INDEX-VAR to the index of NAME's bucket in the table.
679 ;;; Get the info environment that we use for write/modification operations.
680 ;;; This is always the first environment in the list, and must be a
681 ;;; VOLATILE-INFO-ENV.
691 ;;; If Name is already present in the table, then just create or
692 ;;; modify the specified type. Otherwise, add the new name and type,
693 ;;; checking for rehashing.
694 ;;;
695 ;;; We rehash by making a new larger environment, copying all of the
696 ;;; entries into it, then clobbering the old environment with the new
697 ;;; environment's table. We clear the old table to prevent it from
698 ;;; holding onto garbage if it is statically allocated.
699 ;;;
700 ;;; We return the new value so that this can be conveniently used in a
701 ;;; SETF function.
734 new-value))
736 ;;; FIXME: It should be possible to eliminate the hairy compiler macros below
737 ;;; by declaring INFO and (SETF INFO) inline and making a simple compiler macro
738 ;;; for TYPE-INFO-OR-LOSE. (If we didn't worry about efficiency of the
739 ;;; cross-compiler, we could even do it by just making TYPE-INFO-OR-LOSE
740 ;;; foldable.)
742 ;;; INFO is the standard way to access the database. It's settable.
743 ;;;
744 ;;; Return the information of the specified TYPE and CLASS for NAME.
745 ;;; The second value returned is true if there is any such information
746 ;;; recorded. If there is no information, the first value returned is
747 ;;; the default and the second value returned is NIL.
749 ;; FIXME: At some point check systematically to make sure that the
750 ;; system doesn't do any full calls to INFO or (SETF INFO), or at
751 ;; least none in any inner loops.
756 #!-sb-fluid
759 ;; Constant CLASS and TYPE is an overwhelmingly common special case,
760 ;; and we can implement it much more efficiently than the general case.
770 whole))
773 class
774 type
775 name
783 tin
784 new-value
787 tin
788 new-value)))
789 new-value)
790 #!-sb-fluid
792 ;; Not all xc hosts are happy about SETF compiler macros: CMUCL 19
793 ;; does not accept them at all, and older SBCLs give a full warning.
794 ;; So the easy thing is to hide this optimization from all xc hosts.
795 #-sb-xc-host
797 new-value
798 class
799 type
800 name
802 env-list-p))
803 ;; Constant CLASS and TYPE is an overwhelmingly common special case,
804 ;; and we can resolve it much more efficiently than the general
805 ;; case.
811 ,tin
812 ,new-value
815 ,tin
817 whole))
819 ;;; the maximum density of the hashtable in a volatile env (in
820 ;;; names/bucket)
821 ;;;
822 ;;; FIXME: actually seems to be measured in percent, should be
823 ;;; converted to be measured in names/bucket
826 ;;; Make a new volatile environment of the specified size.
830 volatile-info-environment-density))))
835 ;;; Clear the information of the specified TYPE and CLASS for NAME in
836 ;;; the current environment, allowing any inherited info to become
837 ;;; visible. We return true if there was any info.
841 #!-sb-fluid
843 ;; Constant CLASS and TYPE is an overwhelmingly common special case, and
844 ;; we can resolve it much more efficiently than the general case.
848 whole))
857 t))))
858 \f
859 ;;;; *INFO-ENVIRONMENT*
861 ;;; We do info access relative to the current *INFO-ENVIRONMENT*, a
862 ;;; list of INFO-ENVIRONMENT structures.
865 (!cold-init-forms
869 ;;; FIXME: should perhaps be *INFO-ENV-LIST*. And rename
870 ;;; all FOO-INFO-ENVIRONMENT-BAR stuff to FOO-INFO-ENV-BAR.
871 \f
872 ;;;; GET-INFO-VALUE
874 ;;; Return the value of NAME / TYPE from the first environment where
875 ;;; has it defined, or return the default if none does. We used to
876 ;;; do a lot of complicated caching here, but that was removed for
877 ;;; thread-safety reasons.
880 ;; sanity check: If we have screwed up initialization somehow, then
881 ;; *INFO-TYPES* could still be uninitialized at the time we try to
882 ;; get an info value, and then we'd be out of luck. (This happened,
883 ;; and was confusing to debug, when rewriting EVAL-WHEN in
884 ;; sbcl-0.pre7.x.)
893 name)
907 \f
908 ;;;; definitions for function information
912 ;;; the kind of functional object being described. If null, NAME isn't
913 ;;; a known functional object.
918 ;; I'm a little confused what the correct behavior of this default
919 ;; is. It's not clear how to generalize the FBOUNDP expression to
920 ;; the cross-compiler. As far as I can tell, NIL is a safe default
921 ;; -- it might keep the compiler from making some valid
922 ;; optimization, but it shouldn't produce incorrect code. -- WHN
923 ;; 19990330
924 :default
925 #+sb-xc-host nil
928 ;;; The type specifier for this function.
932 :type-spec ctype
933 ;; Again (as in DEFINE-INFO-TYPE :CLASS :FUNCTION :TYPE :KIND) it's
934 ;; not clear how to generalize the FBOUNDP expression to the
935 ;; cross-compiler. -- WHN 19990330
936 :default
942 ;;; the ASSUMED-TYPE for this function, if we have to infer the type
943 ;;; due to not having a declaration or definition
947 ;; FIXME: The type-spec really should be
948 ;; (or approximate-fun-type null)).
949 ;; It was changed to T as a hopefully-temporary hack while getting
950 ;; cold init problems untangled.
953 ;;; where this information came from:
954 ;;; :ASSUMED = from uses of the object
955 ;;; :DEFINED = from examination of the definition
956 ;;; :DECLARED = from a declaration
957 ;;; :DEFINED trumps :ASSUMED, and :DECLARED trumps :DEFINED.
958 ;;; :DEFINED and :ASSUMED are useful for issuing compile-time warnings,
959 ;;; and :DECLARED is useful for ANSIly specializing code which
960 ;;; implements the function, or which uses the function's return values.
965 :default
966 ;; Again (as in DEFINE-INFO-TYPE :CLASS :FUNCTION :TYPE :KIND) it's
967 ;; not clear how to generalize the FBOUNDP expression to the
968 ;; cross-compiler. -- WHN 19990606
972 ;;; something which can be decoded into the inline expansion of the
973 ;;; function, or NIL if there is none
974 ;;;
975 ;;; To inline a function, we want a lambda expression, e.g.
976 ;;; '(LAMBDA (X) (+ X 1)). That can be encoded here in one of two
977 ;;; ways.
978 ;;; * The value in INFO can be the lambda expression itself, e.g.
979 ;;; (SETF (INFO :FUNCTION :INLINE-EXPANSION-DESIGNATOR 'FOO)
980 ;;; '(LAMBDA (X) (+ X 1)))
981 ;;; This is the ordinary way, the natural way of representing e.g.
982 ;;; (DECLAIM (INLINE FOO))
983 ;;; (DEFUN FOO (X) (+ X 1))
984 ;;; * The value in INFO can be a closure which returns the lambda
985 ;;; expression, e.g.
986 ;;; (SETF (INFO :FUNCTION :INLINE-EXPANSION-DESIGNATOR 'BAR-LEFT-CHILD)
987 ;;; (LAMBDA ()
988 ;;; '(LAMBDA (BAR) (BAR-REF BAR 3))))
989 ;;; This twisty way of storing values is supported in order to
990 ;;; allow structure slot accessors, and perhaps later other
991 ;;; stereotyped functions, to be represented compactly.
998 ;;; This specifies whether this function may be expanded inline. If
999 ;;; null, we don't care.
1003 :type-spec inlinep
1006 ;;; a macro-like function which transforms a call to this function
1007 ;;; into some other Lisp form. This expansion is inhibited if inline
1008 ;;; expansion is inhibited
1014 ;;; the macroexpansion function for this macro
1021 ;;; the compiler-macroexpansion function for this macro
1028 ;;; a function which converts this special form into IR1
1034 ;;; If a function is "known" to the compiler, then this is a FUN-INFO
1035 ;;; structure containing the info used to special-case compilation.
1053 \f
1054 ;;;; definitions for other miscellaneous information
1058 ;;; the kind of variable-like thing described
1064 :constant
1067 ;;; the declared type for this variable
1071 :type-spec ctype
1074 ;;; where this type and kind information came from
1081 ;;; the Lisp object which is the value of this constant, if known
1085 :type-spec t
1086 ;; CMU CL used to return two values for (INFO :VARIABLE :CONSTANT-VALUE ..).
1087 ;; Now we don't: it was the last remaining multiple-value return from
1088 ;; the INFO system, and bringing it down to one value lets us simplify
1089 ;; things, especially simplifying the declaration of return types.
1090 ;; Software which used to check the second value (for "is it defined
1091 ;; as a constant?") should check (EQL (INFO :VARIABLE :KIND ..) :CONSTANT)
1092 ;; instead.
1094 name
1097 ;;; the macro-expansion for symbol-macros
1101 :type-spec t
1118 ;;; the kind of type described. We return :INSTANCE for standard types
1119 ;;; that are implemented as structures. For PCL classes, that have
1120 ;;; only been compiled, but not loaded yet, we return
1121 ;;; :FORTHCOMING-DEFCLASS-TYPE.
1127 :default nil
1135 ;;; the expander function for a defined type
1147 ;;; function that parses type specifiers into CTYPE structures
1154 ;;; If true, then the type coresponding to this name. Note that if
1155 ;;; this is a built-in class with a translation, then this is the
1156 ;;; translation, not the class object. This info type keeps track of
1157 ;;; various atomic types (NIL etc.) and also serves as a cache to
1158 ;;; ensure that common standard types (atomic and otherwise) are only
1159 ;;; consed once.
1166 ;;; If this is a class name, then the value is a cons (NAME . CLASS),
1167 ;;; where CLASS may be null if the class hasn't been defined yet. Note
1168 ;;; that for built-in classes, the kind may be :PRIMITIVE and not
1169 ;;; :INSTANCE. The name is in the cons so that we can signal a
1170 ;;; meaningful error if we only have the cons.
1177 ;;; layout for this type being used by the compiler
1189 :type-spec t
1201 :type-spec boolean
1261 ;;; This is used for storing miscellaneous documentation types. The
1262 ;;; stuff is an alist translating documentation kinds to values.
1267 :type-spec list
1270 ;;; Used to record the source location of definitions.
1276 :type-spec t
1282 :type-spec t
1288 :type-spec t
1294 :type-spec t
1298 \f
1299 ;;; Now that we have finished initializing *INFO-CLASSES* and
1300 ;;; *INFO-TYPES* (at compile time), generate code to set them at cold
1301 ;;; load time to the same state they have currently.
1302 (!cold-init-forms
1312 result))
1315 class-info)))
1326 :class class-info
1331 type-info)))
1342 ;;; At cold load time, after the INFO-TYPE objects have been created,
1343 ;;; we can set their DEFAULT and TYPE slots.
1345 `(!cold-init-forms
1348 \f
1349 ;;;; a hack for detecting
1350 ;;;; (DEFUN FOO (X Y)
1351 ;;;; ..
1352 ;;;; (SETF (BAR A FFH) 12) ; compiles to a call to #'(SETF BAR)
1353 ;;;; ..)
1354 ;;;; (DEFSETF BAR SET-BAR) ; can't influence previous compilation
1355 ;;;;
1356 ;;;; KLUDGE: Arguably it should be another class/type combination in
1357 ;;;; the globaldb. However, IMHO the whole globaldb/fdefinition
1358 ;;;; treatment of SETF functions is a mess which ought to be
1359 ;;;; rewritten, and I'm not inclined to mess with it short of that. So
1360 ;;;; I just put this bag on the side of it instead..
1362 ;;; true for symbols FOO which have been assumed to have '(SETF FOO)
1363 ;;; bound to a function
1366 \f