asdf issueshttps://gitlab.common-lisp.net/asdf/asdf/-/issues2022-02-14T20:13:25Zhttps://gitlab.common-lisp.net/asdf/asdf/-/issues/111Automatic self upgrades broken on ECL2022-02-14T20:13:25ZEric TimmonsAutomatic self upgrades broken on ECLIf the ASDF repo is checked out into `~/common-lisp` (or another place the source registry searches), then the first time ASDF automatically upgrades itself will work, but subsequent times will fail.
The proximate cause is that there's ...If the ASDF repo is checked out into `~/common-lisp` (or another place the source registry searches), then the first time ASDF automatically upgrades itself will work, but subsequent times will fail.
The proximate cause is that there's an unbound slot in `action-status` that should *never* be unbound. This also exhausts the stack because when printing the slot-unbound error, it triggers another slot-unbound error ad infinitum.
The root cause is that when loading a fasl, ECL eagerly interns symbols into packages, instead of delaying the intern until the top-level form it appears in is processed. This results in the package of the `stamp` slot name changing at an inopportune time, causing the slot to become unbound in existing instances.
A contributing factor is that the bug is only seen if ASDF locates itself using the source registry. If the `*central-registry*` is used instead, the bug doesn't seem to appear during the self upgrade. There may still be other issues after the self upgrade, however.
I believe that the difference between the central and source registries is likely due to ECL bundling a very old version of ASDF. But I have not been able to prove that yet. It also means that our tests would never catch this because the upgrade tests only use the central registry for configuration.
This is likely an ~"implementation-bug" and has been reported upstream: <https://gitlab.com/embeddable-common-lisp/ecl/-/issues/676>, but they have yet to determine for sure if their current behavior is allowed by the spec or not.
As for remediation on our end: I think if we export `stamp` from the `asdf/action` package that the upgrade will succeed (because the package for the slot name won't change). However, I'm hesitant to do that because there might be other hidden traps after the upgrade has finished.
Another option is to prevent self upgrades on ECL from using a fasl and force them to `cl:load` asdf.lisp. But I'm uncertain how to do that.
The best option is probably just to tell folks running ECL that if they want to upgrade ASDF, they should manually `cl:load` asdf.lisp. Alternatively they can load a fasl, so long as they never load ECL's bundled ASDF.https://gitlab.common-lisp.net/asdf/asdf/-/issues/108Allegro expands compiler macros overeagerly2022-02-14T20:13:58ZEric TimmonsAllegro expands compiler macros overeagerlySometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/l...Sometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/lw50/CLHS/Body/03_bbac.htm) this *must* prevent compiler macro expansion.
However, Allego still expands the compiler macros, potentially resulting in warnings when compiling ASDF.
I noticed when prepping for ASDF 3.4. In addition to failing the same test as ABCL (at <https://abcl.org/trac/ticket/487>), it appears Allegro also expands compiler macros for regular functions as well.
I have not reported. @rgoldman maybe you'd be able to report this to Franz? No rush since we still haven't officially started 3.4 development yet, though.3.4.0https://gitlab.common-lisp.net/asdf/asdf/-/issues/107ABCL expands compiler macros overeagerly2022-02-14T20:14:11ZEric TimmonsABCL expands compiler macros overeagerlySometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/l...Sometimes ASDF/UIOP calls its own deprecated functions. We typically prevent these calls from producing warnings by declaring calls to deprecated functions as `notinline`. According to [3.2.2.1.3](http://www.lispworks.com/documentation/lw50/CLHS/Body/03_bbac.htm) this *must* prevent compiler macro expansion.
However, ABCL still expands the compiler macros in generic functions, potentially resulting in warnings when compiling ASDF.
I noticed when prepping for ASDF 3.4. Reported at <https://abcl.org/trac/ticket/487>. I figured this is worth tracking, so I'm making a new issue category for ~"implementation-bug"3.4.0