| blob | e7c99be59b6d9916191f5561b75e89669416a909 |
1 ;;;; machinery for reporting errors/warnings/notes/whatnot from
2 ;;;; the compiler
4 ;;;; This software is part of the SBCL system. See the README file for
5 ;;;; more information.
6 ;;;;
7 ;;;; This software is derived from the CMU CL system, which was
8 ;;;; written at Carnegie Mellon University and released into the
9 ;;;; public domain. The software is in the public domain and is
10 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
11 ;;;; files for more information.
14 \f
15 ;;;; compiler error context determination
20 #!+sb-doc
21 "The maximum number of enclosing non-original source forms (i.e. from
22 macroexpansion) that we print in full. For additional enclosing forms, we
26 ;;; We separate the determination of compiler error contexts from the
27 ;;; actual signalling of those errors by objectifying the error
28 ;;; context. This allows postponement of the determination of how (and
29 ;;; if) to signal the error.
30 ;;;
31 ;;; We take care not to reference any of the IR1 so that pending
32 ;;; potential error messages won't prevent the IR1 from being GC'd. To
33 ;;; this end, we convert source forms to strings so that source forms
34 ;;; that contain IR1 references (e.g. %DEFUN) don't hold onto the IR.
36 #-no-ansi-print-object
40 ;; a list of the stringified CARs of the enclosing non-original source forms
41 ;; exceeding the *enclosing-source-cutoff*
43 ;; a list of stringified enclosing non-original source forms
45 ;; the stringified form in the original source that expanded into SOURCE
47 ;; a list of prefixes of "interesting" forms that enclose original-source
49 ;; the FILE-INFO-NAME for the relevant FILE-INFO
51 ;; the file position at which the top level form starts, if applicable
53 ;; the original source part of the source path
55 ;; the lexenv active at the time
58 ;;; If true, this is the node which is used as context in compiler warning
59 ;;; messages.
63 ;;; a hashtable mapping macro names to source context parsers. Each parser
64 ;;; function returns the source-context list for that form.
67 ;;; documentation originally from cmu-user.tex:
68 ;;; This macro defines how to extract an abbreviated source context from
69 ;;; the \var{name}d form when it appears in the compiler input.
70 ;;; \var{lambda-list} is a \code{defmacro} style lambda-list used to
71 ;;; parse the arguments. The \var{body} should return a list of
72 ;;; subforms that can be printed on about one line. There are
73 ;;; predefined methods for \code{defstruct}, \code{defmethod}, etc. If
74 ;;; no method is defined, then the first two subforms are returned.
75 ;;; Note that this facility implicitly determines the string name
76 ;;; associated with anonymous functions.
77 ;;; So even though SBCL itself only uses this macro within this file,
78 ;;; it's a reasonable thing to put in SB-EXT in case some dedicated
79 ;;; user wants to do some heavy tweaking to make SBCL give more
80 ;;; informative output about his code.
82 #!+sb-doc
83 "DEFINE-SOURCE-CONTEXT Name Lambda-List Form*
84 This macro defines how to extract an abbreviated source context from the
85 Named form when it appears in the compiler input. Lambda-List is a DEFMACRO
86 style lambda-list used to parse the arguments. The Body should return a
97 name-or-options)))
112 ;;; Return the first two elements of FORM if FORM is a list. Take the
113 ;;; CAR of the second form if appropriate.
125 context-fun-default)))
129 form))))
131 form))))
133 ;;; Given a source path, return the original source form and a
134 ;;; description of the interesting aspects of the context in which it
135 ;;; appeared. The context is a list of lists, one sublist per context
136 ;;; form. The sublist is a list of some of the initial subforms of the
137 ;;; context form.
138 ;;;
139 ;;; For now, we use the first two subforms of each interesting form. A
140 ;;; form is interesting if the first element is a symbol beginning
141 ;;; with "DEF" and it is not the source form. If there is no
142 ;;; DEF-mumble, then we use the outermost containing form. If the
143 ;;; second subform is a list, then in some cases we return the CAR of
144 ;;; that form rather than the whole form (i.e. don't show DEFSTRUCT
145 ;;; options, etc.)
175 ;;; Convert a source form to a string, suitably formatted for use in
176 ;;; compiler warnings.
185 ;;; Return a COMPILER-ERROR-CONTEXT structure describing the current
186 ;;; error context, or NIL if we can't figure anything out. ARGS is a
187 ;;; list of things that are going to be printed out in the error
188 ;;; message, and can thus be blown off when they appear in the source
189 ;;; context.
190 ;;;
191 ;;; If OLD-CONTEXTS is passed in, and includes a context with the
192 ;;; same original source path as the new context would have, the old
193 ;;; context is reused instead, and a secondary value of T is returned.
215 forms))
219 src)
220 nil))
231 :context src-context
233 :file-position
237 pos)
242 nil))))))))))
243 \f
244 ;;;; printing error messages
246 ;;; We save the context information that we printed out most recently
247 ;;; so that we don't print it out redundantly.
249 ;;; The last COMPILER-ERROR-CONTEXT that we printed.
253 ;;; The format string and args for the last error we printed.
259 ;;; The number of times that the last error message has been emitted,
260 ;;; so that we can compress duplicate error messages.
264 ;;; If the last message was given more than once, then print out an
265 ;;; indication of how many times it was repeated. We reset the message
266 ;;; count when we are done.
276 ;;; Print out the message, with appropriate context if we can find it.
277 ;;; If the context is different from the context of the last message
278 ;;; we printed, then we print the context. If the original source is
279 ;;; different from the source we are working on, then we print the
280 ;;; current source in addition to the original source.
281 ;;;
282 ;;; We suppress printing of messages identical to the previous, but
283 ;;; record the number of times that the message is repeated.
350 ;; FIXME: this testing for effective equality of compiler messages
351 ;; is ugly, and really ought to be done at a higher level.
368 ;; effects on the return codes of COMPILE-FILE, so it's nice
369 ;; for users to be able to pick them out by lexical search
370 ;; through the output.
380 ;;; The act of signalling one of these beasts must not cause WARNINGSP
381 ;;; (or FAILUREP) to be set from COMPILE or COMPILE-FILE, so we can't
382 ;;; inherit from WARNING or STYLE-WARNING.
383 ;;;
384 ;;; FIXME: the handling of compiler-notes could be unified with
385 ;;; warnings and style-warnings (see the various handler functions
386 ;;; below).
388 (:documentation
389 "Root of the hierarchy of conditions representing information discovered
390 by the compiler that the user might wish to know, but which does not merit
394 (:documentation
395 "A condition type signalled when the compiler deletes code that the user
403 'simple-compiler-note
409 ,@body
424 ;; Issue a note when we might or might not be in the compiler.
434 ;; (outside logical block, no per-line-prefix)
437 ;;; The politically correct way to print out progress messages and
438 ;;; such like. We clear the current error context so that we know that
439 ;;; it needs to be reprinted, and we also FORCE-OUTPUT so that the
440 ;;; message gets seen right away.
450 ;;; Return a string that somehow names the code in COMPONENT. We use
451 ;;; the source path for the bind node for an arbitrary entry point to
452 ;;; find the source context, then return that as a string.
465 \f
466 ;;;; condition system interface
468 ;;; Keep track of how many times each kind of condition happens.
474 ;;; Keep track of whether any surrounding COMPILE or COMPILE-FILE call
475 ;;; should return WARNINGS-P or FAILURE-P.
479 ;;; condition handlers established by the compiler. We re-signal the
480 ;;; condition, then if it isn't handled, we increment our warning
481 ;;; counter and print the error message.
502 \f
503 ;;;; undefined warnings
506 #!+sb-doc
507 "If non-null, then an upper limit on the number of unknown function or type
508 warnings that the compiler will print for any given name in a single
509 compilation. This prevents excessive amounts of output when the real
512 ;;; Make an entry in the *UNDEFINED-WARNINGS* describing a reference
513 ;;; to NAME of the specified KIND. If we have exceeded the warning
514 ;;; limit, then just increment the count, otherwise note the current
515 ;;; error context.
516 ;;;
517 ;;; Undefined types are noted by a condition handler in
518 ;;; WITH-COMPILATION-UNIT, which can potentially be invoked outside
519 ;;; the compiler, hence the BOUNDP check.
522 ;; Check for boundness so we don't blow up if we're called
523 ;; when IR1 conversion isn't going on.
526 ;; FIXME: I'm pretty sure the INHIBIT-WARNINGS test below
527 ;; isn't a good idea; we should have INHIBIT-WARNINGS
528 ;; affect compiler notes, not STYLE-WARNINGs. And I'm not
529 ;; sure what the BOUNDP '*LEXENV* test above is for; it's
530 ;; likely a good idea, but it probably deserves an
531 ;; explanatory comment.
533 ;; KLUDGE: weird decoupling between here and where we're
534 ;; going to signal the condition. I don't think we can
535 ;; rewrite this using SIGNAL and RESTART-CASE (to take
536 ;; advantage of the (SATISFIES HANDLE-CONDITION-P)
537 ;; handler, because if that doesn't handle it the ordinary
538 ;; compiler handlers will trigger.
562 ;; The compiler tracks full calls that were emitted so that it is possible
563 ;; to detect a definition of a compiler-macro occuring after the first
564 ;; compile-time observed use of (vs. actual call of) that function name.
565 ;;
566 ;; The call count is not reset if the function gets redefined (where the
567 ;; macro could briefly be out-of-sync), but this choice is deliberate.
568 ;; We're not trying to find and report all possible ways that users can
569 ;; introduce semantic glitches, only trying to signal something that is
570 ;; otherwise not always obvious in a totally working built-from-scratch
571 ;; user system, absent any interactive changes.
572 ;;
573 ;; Note on implementation: originally I thought about doing something
574 ;; based on whether the name got an APPROXIMATE-FUN-TYPE and the :WHERE-FROM
575 ;; was :ASSUMED - which together imply that the function did not exist *and*
576 ;; that it was not a NOTINLINE call, however that proved to be fragile.
577 ;; The current approach is reliable, at a cost of ~3 words per function.
578 ;;
583 ;; Show the total number of calls, because otherwise the warning
584 ;; would be worded rather obliquely: "N calls were compiled
585 ;; not in the scope of a notinline declaration" which is, to me,
586 ;; worse than matter-of-factly stating that N calls were compiled.
587 ;; This is why I don't bother collecting both statistics.
588 ;; It's the tail wagging the dog: the message dictates what to track.
590 ;; Grammar note - starting a sentence with a numeral is wrong.
591 (!uncross-format-control
592 "~@<~@(~D~) call~:P to ~/sb!impl:print-symbol-with-prefix/ ~2:*~[~;was~:;were~] ~
593 compiled before a compiler-macro was defined for it. A declaration of ~
594 NOTINLINE at the call site~:P will eliminate this warning, ~
598 ;; Inlining failure scenario 1 [at time of proclamation]:
599 ;; Full call to F is emitted not in the scope of a NOTINLINE, with no definition
600 ;; of F available, and then it's proclaimed INLINE. If F was defined already,
601 ;; it would have been used, unless the expansion limit was hit.
602 ;;
607 ;; Warn only if the the compiler did not have the expansion.
609 ;; and if nothing was previously known about inline status
610 ;; so that repeated proclamations don't warn. NIL is a valid
611 ;; value for :inlinep in the globaldb so use the 2nd result.
614 'inlining-dependency-failure
615 :format-control
616 (!uncross-format-control
617 "~@<Proclaiming ~/sb!impl:print-symbol-with-prefix/ to be INLINE, but ~D call~:P to it ~
618 ~:*~[~;was~:;were~] previously compiled. A declaration of NOTINLINE ~
619 at the call site~:P will eliminate this warning, as will proclaiming ~
623 ;; Inlining failure scenario 2 [at time of call]:
624 ;; F is not defined, but either proclaimed INLINE and not declared
625 ;; locally notinline, or expressly declared locally inline.
626 ;; Warn about emitting a full call at that time.
627 ;;
628 ;; It could be friendlier to present this warning as one summary
629 ;; at the end of a compilation unit, but that is not as important as
630 ;; just getting the warning across.
631 ;; [The point of deferring a warning is that some future event can resolve it
632 ;; - like an undefined function becoming defined - but there's nothing
633 ;; that can resolve absence of a definition at a point when it was needed]
634 ;;
635 ;; Should we regard it as more serious if the inline-ness of the global
636 ;; function was lexically declared? Is "Inline F here" stronger than
637 ;; "It would generally be a good idea to inline F everywhere"?
638 ;;
639 ;; Don't be too put off by the above concerns though. It's not customary
640 ;; to write (DECLAIM INLINE) after the function, or so far separated from it
641 ;; that intervening callers know it to be proclaimed inline, and would have
642 ;; liked to have a definition, but didn't.
643 ;;
645 ;; Do nothing if the inline expansion is known - it wasn't used
646 ;; because of the expansion limit, which is a different problem.
649 ;; This function is only called by PONDER-FULL-CALL when NAME
650 ;; is not lexically NOTINLINE, so therefore if it is globally INLINE,
651 ;; there was no local declaration to the contrary.
658 ;; Set a bit saying that a warning about the call was generated,
659 ;; which suppresses the warning about either a later
660 ;; call or a later proclamation.
662 ;; While there could be a different style-warning for
663 ;; "You should put the DEFUN after the DECLAIM"
664 ;; if they appeared reversed, it's not ideal to warn as soon as that.
665 ;; It's only a problem if something failed to be inlined in account of it.
667 'inlining-dependency-failure
668 :format-control
670 (!uncross-format-control
671 "~@<Call to ~/sb!impl:print-symbol-with-prefix/ could not be inlined because no definition ~
673 ;; This message sort of implies that source form is the
674 ;; only reasonable representation in which an inline definition
675 ;; could have been saved, which isn't in general true - it could
676 ;; be saved as a parsed AST - but I don't really know how else to
677 ;; phrase this. And it happens to be true in SBCL, so it's not wrong.
678 (!uncross-format-control
679 "~@<Call to ~/sb!impl:print-symbol-with-prefix/ could not be inlined because its source code ~
680 was not saved. A global INLINE or SB-EXT:MAYBE-INLINE proclamation must be ~