From: Pip Cet <pipcet@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 46834@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
Subject: bug#46834: 28.0.50; byte-compiling the standard counter closure fails
Date: Mon, 1 Mar 2021 17:13:34 +0000 [thread overview]
Message-ID: <CAOqdjBd2qcS9sS9R0s6JCzA5SR+fn95Unb9_3MG_WChG_GH3Aw@mail.gmail.com> (raw)
In-Reply-To: <jwvy2f6q08r.fsf-monnier+emacs@gnu.org>
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
next prev parent reply other threads:[~2021-03-01 17:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-28 15:04 bug#46834: 28.0.50; byte-compiling the standard counter closure fails Pip Cet
2021-02-28 19:57 ` Pip Cet
2021-02-28 20:34 ` Pip Cet
2021-03-01 14:23 ` Stefan Monnier
2021-03-01 15:01 ` Pip Cet
2021-03-01 16:02 ` Stefan Monnier
2021-03-02 7:00 ` Lars Ingebrigtsen
2021-03-02 7:31 ` Pip Cet
2021-03-02 7:34 ` Lars Ingebrigtsen
2021-03-02 7:36 ` Pip Cet
2021-03-02 13:16 ` Eli Zaretskii
2021-03-02 13:19 ` Pip Cet
2021-03-02 13:48 ` Eli Zaretskii
2021-03-01 13:16 ` Lars Ingebrigtsen
2021-03-01 14:34 ` Stefan Monnier
2021-03-01 15:16 ` Pip Cet
2021-03-01 16:15 ` Stefan Monnier
2021-03-01 16:41 ` Pip Cet
2021-03-01 17:01 ` Stefan Monnier
2021-03-01 17:13 ` Pip Cet [this message]
2021-03-01 16:31 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOqdjBd2qcS9sS9R0s6JCzA5SR+fn95Unb9_3MG_WChG_GH3Aw@mail.gmail.com \
--to=pipcet@gmail.com \
--cc=46834@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).