bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function

[Stefan Monnier]

> Thanks, that's useful information.  But it doesn't address my questions
> in the slightest.

I'm sorry.  I guess I still haven't figured what it is that I assume as
known but which you don't actually know.

> Would you please answer these specific questions, now, to help me
> understand this difficult mechanism.  Thanks!

[ I assume you're talking about the questions below.  ]

>> >> It's not a function but a special operator, which is thus handled in
>> >> a hard-coded way by `macroexp--expand-all`.
>> > Is it the case that this hard-coded handling for function is prevented
>> > by the macro "expansion" of (function F)?
>> Yes, we first expand the macros and then try to handle the result
>> which should be one of the hard-coded cases (or is otherwise assumed to
>> be a function call).
> Are you talking about the code in macroexp--expand-all, here?

Yes.

> By "macros", do you mean cl-flet and cl-labels here (as opposed to
> function)?

I'm talking about any call to an identifier that is "currently" defined
as a macro.  This can be either because the `symbol-function` holds
something of the form `(macro . <DEF>)` or because
`macroexpand-all-environment` has an entry for that identifier.

> What do you mean by "hard-coded cases"?

The face that `macroexp--expand-all` handles the `function` identifier
as follows:

          (pcase form
            [...]
            (`(,(or 'function 'quote) . ,_) form)
            [...]


-- Stefan