Compile-time function definition/call compatibility checking is misapplied for redefinitions in the presence of forward or self-references with inlining
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Triaged
|
Low
|
Unassigned |
Bug Description
What I do:
;;; Compile a file containing this with slime:
(defun forward-referencing (first)
(forward-
(defun forward-referenced (first)
(or first (forward-
;;; Now compile these redefinitions:
(defun forward-referencing (first second)
(forward-
(defun forward-referenced (first second)
(or first (forward-
What happens:
A style-warning is issued at the site of the call to forward-referenced:
"The function was called with two arguments, but wants exactly one."
What I expected to happen:
I think this type of error should be delayed until the end of the compilation unit and then "cancelled" if a redefinition that solves the mismatch is found.
Analysis:
I did quite a bit of testing on this. It appears that the problem is due to redefinition + forward or self-references + inlining. As evidence, simply adding (declare (notinline forward-
At first I thought the problem was that the call to forward-referenced was being inlined before its redefinition was seen, however I tested this assumption by calling forward-referenced with NIL at the REPL after doing these redefinitions (starting with the same definitions as I started with above):
(defun forward-referencing (first)
(declare (inline forward-
(forward-
(defun forward-referenced (first)
(print first)
(or first (forward-
-| NIL
-| T
=> T
The result indicates that forward-referencing correctly picked up the new definition.
So, perhaps the machinery that inlines calls and the one that signals warning for apparent definition/call mismatches are distinct and only the latter behaves incorrectly with redefinition + forward or self-reference + inlining?
SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
*features*:
(:SWANK :QUICKLISP :SB-BSD-
:SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
:SB-SOURCE-
:LARGEFILE :GENCGC :STACK-
:COMPARE-
:STACK-
:STACK-
:CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-
:OS-PROVIDES-
Not inlining. NOTINLINE is just taken to mean "assume nothing about this", so anything known about the type is ignored.
But yes, in case the problem call isn't _actually_ inlined, it would be nice to shut down these warnings if the compilation unit solves the issues.