bug#46834: 28.0.50; byte-compiling the standard counter closure fails

[Pip Cet]

On Mon, Mar 1, 2021 at 5:01 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> > That said, the comment in byte-compile--reify-function is incorrect:
> >> [ I don't see which comment you're referring to.  ]
> > The docstring, sorry. It says the return value evaluates to FUN, which
> > is incorrect (but, IMHO at least, this behavior is desirable and
> > consistent, at least, with the way byte-compile changes string
> > identities).
>
> Ah, that.  Yes, we could clarify that it's not 100% equivalent, but it's
> an internal function anyway.  The doc there is only intended to explain
> what the function is supposed to do.

I think we should, generally, document that bytecode compilation (and
native compilation soon) take a snapshot of the function as it stands
at compilation time. You can't modify the lambda list you turned into
a native function and expect the native function to change.

> > I agree, it is repulsive. I wasn't going to mention it for that reason
> > :-) (Also for the reason that I wasn't sure whether anything would
> > break out of the cl-symbol-macrolet jail (no luck so far...))
>
> I'm not quite sure it'll always get it right, indeed, tho I think
> it should.

Haven't found a way to break out yet, but this detects that we're in
c-s-m, at least:

(let ((cell (cons nil nil)))
  (cl-symbol-macrolet ((x (car cell)))
    (condition-case error
        (funcall #'setq x 5)
      (error (message "I know I'm in a c-s-m jail!")))))

And, yes, that relies on another bug...

Pip