Re: Lisp files that load cl-lib in problematical ways

[Alan Mackenzie]

Hello, Richard.

On Sat, Oct 21, 2023 at 01:21:16 -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > Quite a lot of the function calls are things like cl-assert, cl-incf, or
>   > cl-defgeneric, which won't cause the loading of cl- until they are
>   > actually run.

> Those are macros, right?  These macros are not supposed to need cl-lib
> at run time; they are supposed to be handled (when the code is
> compiled) at compile time.

A lot of them are macros, yes.  When I filter out the macros from my
list, and also functions of the form cl-generic-* and cl--generic-*
(cl-generic is loaded at dump time), I'm left with these functions:

* cl-call-next-method
* cl--class-parents
cl-member
* cl-next-method-p
cl-old-struct-compat-mode
cl-plusp
cl-print-object
* cl--slot-descriptor-name
* cl--slot-descriptor-props
* cl--struct-class-children-sym
* cl--struct-class-parents
* cl--struct-register-child

..  I've marked with an asterisk those that are in cl-preloaded.el or
cl-generic.el.

Of the remaining functions:
(i) cl-member is used only in a compiler macro for add-to-list in
  subr.el.  This is OK.
(ii) cl-old-struct-compat-mode is called from cl-struct-define in
  cl-preloaded.el.  It is an auto-load function which only gets loaded
  when cl-struct-define is called with an obsolete calling convention.
(iii) cl-plusp is a defsubst, effectively a macro.
(iv) cl-print-object is a defgeneric function in cl-print.el.  There is
  a cl-defmethod of cl-print-object in nadvice.el.  This contains calls
  to cl-print-object methods defined in cl-print.el  Since
  cl-print-object is an auto-load, this should only cause cl-lib to get
  loaded at run time, not dump time.

So it would appear there are no cl- functions used in the dumped .el
files which would cause cl-lib to be loaded.

There was only one cl- special variable which got bound to a non-nil
value in the dumped .el files.  That was cl--generic-edebug-name,
defined and bound in cl-generic.el.

It would take a more rigorous analysis to find any cl- variables bound
to nil in these files.

> Maybe people changed these macros and caused them to load cl-lib.

> But maybe not all of them.

I'm convinced this is not the case, unless it is by binding cl- special
variables to nil.

> I looked into cl-assert and found that it generates a call to
> cl--assertion-failed, which is defined in xo cl-preloaded.el.
> So I think that macro is ok -- the problem in question doesn't
> seem to happen in cl-assert.

> Which of the cl- macros really generate calls that require cl-lib
> to be loaded?  We should fix those.

After scanning the source code, I'm convinced there aren't any, with the
above proviso.

> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

-- 
Alan Mackenzie (Nuremberg, Germany).