Help sought: Details of byte-compile-make-closure, please.

Help sought: Details of byte-compile-make-closure, please.

[Alan Mackenzie]

Hello, Emacs.

Whilst fixing bug #55323, I came across more places in the byte compiler
where we might need to strip positions from symbols.

In particular, in byte-compile-make-closure (in bytecomp.el), there are
two calls to make-byte-code.  These calls have (amongst other things) an
ARG argument and an &optional INTERACTIVE-SPEC argument.

The comments around this part of the code are rather sparse, and I can't
find any documentation for internal-make-closure.

My questions:

(i) Does byte-compile-make-closure get called at all when
lexical-binding is nil?

(ii) Is the ARG argument to make-byte-code, extracted from the parameter
FORM always in the bit-encoded form (7 bits for minimum args, 7 bits for
maximum args and 1 bit for &rest), or might it sometimes be an "old
fashioned" list of symbols?  I need to know this because such a list
might need positions stripping from these symbols.

(iii) Is there ever a non-null interactive form contained in the
parameter FORM?  (If so, it comes in in a &rest parameter and is
forwarded to make-byte-code in an &optional argument.)  Such an
interactive form may need positions stripping from its symbols too.

Thanks in advance for the help!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Help sought: Details of byte-compile-make-closure, please.

[Eli Zaretskii]

> Date: Tue, 17 May 2022 09:15:37 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> The comments around this part of the code are rather sparse, and I can't
> find any documentation for internal-make-closure.

Please improve the comments when you eventually learn the answers to
your questions.

TIA

Re: Help sought: Details of byte-compile-make-closure, please.

[Stefan Monnier]

Alan Mackenzie [2022-05-17 09:15:37] wrote:
> Whilst fixing bug #55323, I came across more places in the byte compiler
> where we might need to strip positions from symbols.

[ Sidenote: I don't understand why you'd need to strip the positions
  manually here.  Is it for the `(apply #'make-byte-code ...` case,
  because your later position-stripping code doesn't recurse within
  byte-code functions?  ]

> (i) Does byte-compile-make-closure get called at all when
> lexical-binding is nil?

No.

> (ii) Is the ARG argument to make-byte-code, extracted from the parameter
> FORM always in the bit-encoded form (7 bits for minimum args, 7 bits for
> maximum args and 1 bit for &rest), or might it sometimes be an "old
> fashioned" list of symbols?

It's never the "old fashioned" list of symbols, because that's only
used for lexical-binding==nil functions as you can see in
`byte-compile-lambda` where we do:

	     (apply #'make-byte-code
		    (if lexical-binding
			(byte-compile-make-args-desc arglist)
		      bare-arglist)

> I need to know this because such a list
> might need positions stripping from these symbols.

Indeed.

> (iii) Is there ever a non-null interactive form contained in the
> parameter FORM?

Usually not, but sometimes yes.

> (If so, it comes in in a &rest parameter and is
> forwarded to make-byte-code in an &optional argument.)  Such an
> interactive form may need positions stripping from its symbols too.

FWIW, I think that is `byte-compile-lambda` strips the positions then
`byte-compile-make-closure` won't need to (since all the args, constant
vector, interactive form, ... comes from the byte code returned by
`byte-compile-make-closure`).

Oh, actually not quite: the `docstring-exp` needs to be stripped before
passing it to `eval`.


        Stefan