bug#55972: 28.1; Package quickstart generated for large number of packages generates byte-code string larger than 64K, triggering bytecode overflow error

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Tue, Jun 14, 2022 at 12:29 PM Mattias Engdegård <mattiase@acm.org> wrote:

> If, as seems to be the case, byte-compile-keep-pending is only used for
> top-level forms, then this patch may even be correct. Does it solve your
> problems?
> It still seems to generate far bigger bytecode chunks than the 300 cutoff
> would imply but that's perhaps just a matter of calling the function in
> more places.
>
>
Thanks, Mattias, it does work.

I was going to ask about directly addressing the underlying problem by
tail-calling
or trampolining to a byte-code vector in the constants array, but then
realized you would have to
either make sure there could be no "gotos" between the segments or do a
real trampoline to
an explicit label.  And in either case you would have to save the contents
of the stack frame
and reinstate them in the continuation byte-code call, and I don't see any
byte-codes that would
support that.   Otherwise you could only do it when you know there is no
stack in use, which is what I believe
your solution effectively does.

On the other hand, given the code for patching up byte-code in
byte-compile-lapcode, you could
explicitly byte-compile a thunk for every top-level expression, then glue
them together until they would exceed
the 65K pc limit, then do another segment, etc, and do a simple trampoline
between the resulting byte-code vectors,
or no trampoline if there were only one required.  Strictly speaking,
gluing them all together is really an optimization
of creating byte-code vectors (thunks) for each top-level expression, and
looping over the collection of them, invoking
each one in turn.

As long as I'm looking at the compile log, I also see a lot of errors of
the form:
     package-quickstart2.el:14739:39: Warning: The compiler ignores
‘autoload’ except at top level.  You should
         probably put the autoload of the macro ‘bind-map-for-minor-mode’
at top-level.
This message is only reported for macros - there are plenty of autoload
expressions that do not generate this
message despite being in the same kind of "let" form.

Lynn

[-- Attachment #2: Type: text/html, Size: 2740 bytes --]