bug#33848: Store references in SBCL-compiled code are "invisible"

[Mark H Weaver <mhw@netris.org>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> With this patch applied, all graft derivations will be rebuilt, but
>> *only* grafts.  When it's ready (i.e. when it has better comments,
>> docstrings, etc), this change is perfectly appropriate for 'master'.
>
> The GC’s scanner still gets it wrong though.  I wonder whether having
> the grafting code more capable than the scanner could lead to bad
> surprises.  WDYT?

I've thought about it, and I've been unable to think of any
disadvantage to making the grafter more capable than the scanner.
It seems to me a pure win.

That the scanner fails to find all references is clearly an important
problem that should be fixed ASAP, but as far as I can tell, improving
the grafter would not make that problem any worse or create any new
problems.

Improving the grafter should have the following effects:

(1) Reducing the number of cases where ungrafted code with security
    flaws is being used on our systems.

(2) Fixing problems in our Fish, Nyxt, and Common Lisp packages.

Improving the scanner, or adding phases to selected packages or build
systems to copy hidden references to an ASCII file, should have the
following effects:

(1) Reducing the number of cases where run-time dependencies are not
    known to Guix, which could lead to dependencies being prematurely
    GC'd or excluded from things like "guix pack".

So, it seems to me that we should persue both of these improvements
concurrently, and I see no practical advantage to postponing one for the
sake of rolling them both out at the same time.  Of course, I welcome
other opinions on this.

What do you think?

     Thanks,
       Mark