| blob | f2febf16f1e968628962fff7575974381a0bc2f6 |
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
239 nil))))))))))
240 \f
241 ;;;; printing error messages
243 ;;; We save the context information that we printed out most recently
244 ;;; so that we don't print it out redundantly.
246 ;;; The last COMPILER-ERROR-CONTEXT that we printed.
250 ;;; The format string and args for the last error we printed.
256 ;;; The number of times that the last error message has been emitted,
257 ;;; so that we can compress duplicate error messages.
261 ;;; If the last message was given more than once, then print out an
262 ;;; indication of how many times it was repeated. We reset the message
263 ;;; count when we are done.
273 ;;; Print out the message, with appropriate context if we can find it.
274 ;;; If the context is different from the context of the last message
275 ;;; we printed, then we print the context. If the original source is
276 ;;; different from the source we are working on, then we print the
277 ;;; current source in addition to the original source.
278 ;;;
279 ;;; We suppress printing of messages identical to the previous, but
280 ;;; record the number of times that the message is repeated.
347 ;; FIXME: this testing for effective equality of compiler messages
348 ;; is ugly, and really ought to be done at a higher level.
365 ;; effects on the return codes of COMPILE-FILE, so it's nice
366 ;; for users to be able to pick them out by lexical search
367 ;; through the output.
377 ;;; The act of signalling one of these beasts must not cause WARNINGSP
378 ;;; (or FAILUREP) to be set from COMPILE or COMPILE-FILE, so we can't
379 ;;; inherit from WARNING or STYLE-WARNING.
380 ;;;
381 ;;; FIXME: the handling of compiler-notes could be unified with
382 ;;; warnings and style-warnings (see the various handler functions
383 ;;; below).
385 (:documentation
386 "Root of the hierarchy of conditions representing information discovered
387 by the compiler that the user might wish to know, but which does not merit
391 (:documentation
392 "A condition type signalled when the compiler deletes code that the user
400 'simple-compiler-note
406 ,@body
421 ;; Issue a note when we might or might not be in the compiler.
431 ;; (outside logical block, no per-line-prefix)
434 ;;; The politically correct way to print out progress messages and
435 ;;; such like. We clear the current error context so that we know that
436 ;;; it needs to be reprinted, and we also FORCE-OUTPUT so that the
437 ;;; message gets seen right away.
447 ;;; Return a string that somehow names the code in COMPONENT. We use
448 ;;; the source path for the bind node for an arbitrary entry point to
449 ;;; find the source context, then return that as a string.
462 \f
463 ;;;; condition system interface
465 ;;; Keep track of how many times each kind of condition happens.
471 ;;; Keep track of whether any surrounding COMPILE or COMPILE-FILE call
472 ;;; should return WARNINGS-P or FAILURE-P.
476 ;;; condition handlers established by the compiler. We re-signal the
477 ;;; condition, then if it isn't handled, we increment our warning
478 ;;; counter and print the error message.
499 \f
500 ;;;; undefined warnings
503 #!+sb-doc
504 "If non-null, then an upper limit on the number of unknown function or type
505 warnings that the compiler will print for any given name in a single
506 compilation. This prevents excessive amounts of output when the real
509 ;;; Make an entry in the *UNDEFINED-WARNINGS* describing a reference
510 ;;; to NAME of the specified KIND. If we have exceeded the warning
511 ;;; limit, then just increment the count, otherwise note the current
512 ;;; error context.
513 ;;;
514 ;;; Undefined types are noted by a condition handler in
515 ;;; WITH-COMPILATION-UNIT, which can potentially be invoked outside
516 ;;; the compiler, hence the BOUNDP check.
519 ;; Check for boundness so we don't blow up if we're called
520 ;; when IR1 conversion isn't going on.
523 ;; FIXME: I'm pretty sure the INHIBIT-WARNINGS test below
524 ;; isn't a good idea; we should have INHIBIT-WARNINGS
525 ;; affect compiler notes, not STYLE-WARNINGs. And I'm not
526 ;; sure what the BOUNDP '*LEXENV* test above is for; it's
527 ;; likely a good idea, but it probably deserves an
528 ;; explanatory comment.
530 ;; KLUDGE: weird decoupling between here and where we're
531 ;; going to signal the condition. I don't think we can
532 ;; rewrite this using SIGNAL and RESTART-CASE (to take
533 ;; advantage of the (SATISFIES HANDLE-CONDITION-P)
534 ;; handler, because if that doesn't handle it the ordinary
535 ;; compiler handlers will trigger.
559 ;; The compiler tracks full calls that were emitted so that it is possible
560 ;; to detect a definition of a compiler-macro occuring after the first
561 ;; compile-time observed use of (vs. actual call of) that function name.
562 ;;
563 ;; The call count is not reset if the function gets redefined (where the
564 ;; macro could briefly be out-of-sync), but this choice is deliberate.
565 ;; We're not trying to find and report all possible ways that users can
566 ;; introduce semantic glitches, only trying to signal something that is
567 ;; otherwise not always obvious in a totally working built-from-scratch
568 ;; user system, absent any interactive changes.
569 ;;
570 ;; Note on implementation: originally I thought about doing something
571 ;; based on whether the name got an APPROXIMATE-FUN-TYPE and the :WHERE-FROM
572 ;; was :ASSUMED - which together imply that the function did not exist *and*
573 ;; that it was not a NOTINLINE call, however that proved to be fragile.
574 ;; The current approach is reliable, at a cost of ~3 words per function.
575 ;;
580 ;; Show the total number of calls, because otherwise the warning
581 ;; would be worded rather obliquely: "N calls were compiled
582 ;; not in the scope of a notinline declaration" which is, to me,
583 ;; worse than matter-of-factly stating that N calls were compiled.
584 ;; This is why I don't bother collecting both statistics.
585 ;; It's the tail wagging the dog: the message dictates what to track.
587 ;; Grammar note - starting a sentence with a numeral is wrong.
588 (!uncross-format-control
589 "~@<~@(~D~) call~:P to ~/sb!impl:print-symbol-with-prefix/ ~2:*~[~;was~:;were~] ~
590 compiled before a compiler-macro was defined for it. A declaration of ~
591 NOTINLINE at the call site~:P will eliminate this warning, ~
595 ;; Inlining failure scenario 1 [at time of proclamation]:
596 ;; Full call to F is emitted not in the scope of a NOTINLINE, with no definition
597 ;; of F available, and then it's proclaimed INLINE. If F was defined already,
598 ;; it would have been used, unless the expansion limit was hit.
599 ;;
604 ;; Warn only if the the compiler did not have the expansion.
606 ;; and if nothing was previously known about inline status
607 ;; so that repeated proclamations don't warn. NIL is a valid
608 ;; value for :inlinep in the globaldb so use the 2nd result.
611 'inlining-dependency-failure
612 :format-control
613 (!uncross-format-control
614 "~@<Proclaiming ~/sb!impl:print-symbol-with-prefix/ to be INLINE, but ~D call~:P to it ~
615 ~:*~[~;was~:;were~] previously compiled. A declaration of NOTINLINE ~
616 at the call site~:P will eliminate this warning, as will proclaiming ~
620 ;; Inlining failure scenario 2 [at time of call]:
621 ;; F is not defined, but either proclaimed INLINE and not declared
622 ;; locally notinline, or expressly declared locally inline.
623 ;; Warn about emitting a full call at that time.
624 ;;
625 ;; It could be friendlier to present this warning as one summary
626 ;; at the end of a compilation unit, but that is not as important as
627 ;; just getting the warning across.
628 ;; [The point of deferring a warning is that some future event can resolve it
629 ;; - like an undefined function becoming defined - but there's nothing
630 ;; that can resolve absence of a definition at a point when it was needed]
631 ;;
632 ;; Should we regard it as more serious if the inline-ness of the global
633 ;; function was lexically declared? Is "Inline F here" stronger than
634 ;; "It would generally be a good idea to inline F everywhere"?
635 ;;
636 ;; Don't be too put off by the above concerns though. It's not customary
637 ;; to write (DECLAIM INLINE) after the function, or so far separated from it
638 ;; that intervening callers know it to be proclaimed inline, and would have
639 ;; liked to have a definition, but didn't.
640 ;;
642 ;; Do nothing if the inline expansion is known - it wasn't used
643 ;; because of the expansion limit, which is a different problem.
646 ;; This function is only called by PONDER-FULL-CALL when NAME
647 ;; is not lexically NOTINLINE, so therefore if it is globally INLINE,
648 ;; there was no local declaration to the contrary.
655 ;; Set a bit saying that a warning about the call was generated,
656 ;; which suppresses the warning about either a later
657 ;; call or a later proclamation.
659 ;; While there could be a different style-warning for
660 ;; "You should put the DEFUN after the DECLAIM"
661 ;; if they appeared reversed, it's not ideal to warn as soon as that.
662 ;; It's only a problem if something failed to be inlined in account of it.
664 'inlining-dependency-failure
665 :format-control
667 (!uncross-format-control
668 "~@<Call to ~/sb!impl:print-symbol-with-prefix/ could not be inlined because no definition ~
670 ;; This message sort of implies that source form is the
671 ;; only reasonable representation in which an inline definition
672 ;; could have been saved, which isn't in general true - it could
673 ;; be saved as a parsed AST - but I don't really know how else to
674 ;; phrase this. And it happens to be true in SBCL, so it's not wrong.
675 (!uncross-format-control
676 "~@<Call to ~/sb!impl:print-symbol-with-prefix/ could not be inlined because its source code ~
677 was not saved. A global INLINE or SB-EXT:MAYBE-INLINE proclamation must be ~