backtrace missing one argument for (some?) XEPs

[Nikodemus Siivola]

Test case:

  (defun foo (x)
    (eval `(/ 1 ,x)))
  (foo 0)

shows

  0: (SB-KERNEL::INTEGER-/-INTEGER 1 0)
  1: ((SB-C::TL-XEP /) 2 1)[:EXTERNAL]

in the backtrace (with *SHOW-ENTRY-POINT-DETAILS*).

[Nikodemus Siivola (nikodemus)]

Upgrading because I know understand what is going on a bit better: this can lead to important information missing from backtraces.

Following functions demonstrate how file-compiling them will show only the required arguments for their TL-XEPs in the backtrace.

(defun fe0 (&rest rest)
  (let ((* *))
    (apply '/ rest)))

(defun fe1 (x &rest rest)
  (let ((* *))
    (apply '/ x rest)))

(defun fe2 (x y &rest rest)
  (let ((* *))
    (apply '/ x y rest)))

(fe0 10 11 0)

(fe1 10 11 0)

(fe2 10 11 0)

[Nikodemus Siivola (nikodemus)]

The issue is not file-compilation vs. non-file compilation.

The issue is that MAKE-FUNCTIONAL-FROM-TOPLEVEL-LAMBDA doesn't cross-link the original lambda and the generated XEP and then set the reoptimize flag.

Exactly *why* this generates the behaviour observed is not clear to me yet, but if MAKE-FUNCTIONAL-FROM-TOPLEVEL-LAMBDA is made more isomorphic with MAKE-XEP the issue disappears.

diff --git a/src/compiler/main.lisp b/src/compiler/main.lisp
index c0c6a81..b4258f5 100644
--- a/src/compiler/main.lisp
+++ b/src/compiler/main.lisp
@@ -1115,6 +1115,8 @@ Examples:
       (when name
         (assert-global-function-definition-type name locall-fun))
       (setf (functional-entry-fun fun) locall-fun
+ (functional-entry-fun locall-fun) fun
+ (component-reanalyze component) t
             (functional-kind fun) :external
             (functional-has-external-references-p locall-fun) t
             (functional-has-external-references-p fun) t)

Fixed in my pending tree. Will likely commit after freeze despite imperfect understanding.

[Nikodemus Siivola (nikodemus)]

Related to bug 384892. The snippet above is a move in the right direction, but not the whole story. Something is confused here, but it could just be me.

[Nikodemus Siivola (nikodemus)]

Attached patch fixes both this and bug 384892.

It also bloats the core by ~2%. At least some of the bloat is due to the cross-compiler getting sloppy due to the patch: for reasons I don't yet understand eg. READ-RIGHT-PAREN is compiled with a non-tail-call, and ends up needing a trap for NIL-FUNCTION-RETURNED.

[Nikodemus Siivola (nikodemus)]

In 1.0.44.4.