GNU bug report logs -
#46834
28.0.50; byte-compiling the standard counter closure fails
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Sun, 28 Feb 2021 18:08:02 UTC
Severity: normal
Found in version 28.0.50
Done: Pip Cet <pipcet <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Mon, Mar 1, 2021 at 5:01 PM Stefan Monnier <monnier <at> 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
This bug report was last modified 4 years and 85 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.