GNU bug report logs - #15814
24.3.50; Signal error on malformed bindings in `cl-symbol-macrolet' (patch)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15814 in the body.
You can then email your comments to 15814 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Tue, 05 Nov 2013 15:40:22 -0500

[Message part 1 (text/plain, inline)]

`cl-symbol-macrolet' silently accepts both of the following forms:

(cl-symbol-macrolet ((foo bar baz) ...) ...)
(cl-symbol-macrolet ((foo) ...) ...)

In the former case, baz is ignored; in the latter case, foo is bound to
nil.

According to the CL docs, neither of these is valid.  (Not to mention,
they are both errors in Common Lisp.)  The attached patch asserts
properly formed bindings.

I checked the Emacs source to make sure there's no code in there relying
on this behavior.

[cl-macs.el.patch (text/x-diff, inline)]

From d6feb1195b8dc8f204d49761bfa828facbb4ba57 Mon Sep 17 00:00:00 2001
From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Date: Tue, 5 Nov 2013 14:36:32 -0500
Subject: [PATCH] Signal error with malformed bindings in cl-symbol-macrolet.

---
 lisp/ChangeLog             | 5 +++++
 lisp/emacs-lisp/cl-macs.el | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 828fcda..a4ae0ca 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2013-11-05  Nathan Trapuzzano  <nbtrap <at> nbtrap.com>
+
+	* emacs-lisp/cl-macs.el (cl-symbol-macrolet): Signal error with
+	malformed bindings form.
+
 2013-11-05  Eli Zaretskii  <eliz <at> gnu.org>
 
 	* international/quail.el (quail-help): Be more explicit about the
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 60fdc09..1e277f7 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -1988,6 +1988,8 @@ by EXPANSION, and (setq NAME ...) will act like (setf EXPANSION ...).
        (cl-symbol-macrolet ,(cdr bindings) ,@body)))
    ((null bindings) (macroexp-progn body))
    (t
+    (cl-assert (and (cdar bindings) (null (cl-cddar bindings))) nil
+	       "Malformed `cl-symbol-macrolet' binding: %S" (car bindings))
     (let ((previous-macroexpand (symbol-function 'macroexpand)))
       (unwind-protect
           (progn
-- 
1.8.4.2

Message #8 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Tue, 05 Nov 2013 19:46:45 -0500

> --- a/lisp/emacs-lisp/cl-macs.el
> +++ b/lisp/emacs-lisp/cl-macs.el
> @@ -1988,6 +1988,8 @@ by EXPANSION, and (setq NAME ...) will act like (setf EXPANSION ...).
>         (cl-symbol-macrolet ,(cdr bindings) ,@body)))
>     ((null bindings) (macroexp-progn body))
>     (t
> +    (cl-assert (and (cdar bindings) (null (cl-cddar bindings))) nil
> +	       "Malformed `cl-symbol-macrolet' binding: %S" (car bindings))
>      (let ((previous-macroexpand (symbol-function 'macroexpand)))
>        (unwind-protect
>            (progn

Good idea.  Could you try and use macroexp--warn-and-return instead, so
we get a file&line location when byte-compiling?

BTW, the same holds for the "let" sanity checks you added to cconv
(which should probably be moved to macroexp, now that I think about it,
so we can remove them from bytecomp.el).


        Stefan

Message #11 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Tue, 05 Nov 2013 21:19:06 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Good idea.  Could you try and use macroexp--warn-and-return instead, so
> we get a file&line location when byte-compiling?

I'm not certain what you mean here.  You seem to agree that this is an
error, but `macroexp--warn-and-return' doesn't signal an error--it just
prints a warning.  If we do something like this:

  (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
                     (car bindings))))
    (macroexp--warn-and-return msg `(error "%s" ,msg)))

we'll get a warning at compile time and an error at run time.  Is this
what you have in mind?  Shouldn't we signal the error as early as
possible?  Perhaps there is some Emacs convention that I'm not aware of
in this regard.

> BTW, the same holds for the "let" sanity checks you added to cconv
> (which should probably be moved to macroexp, now that I think about it,
> so we can remove them from bytecomp.el).

I don't understand this either.  By "moved to macroexp", do you just
mean that the sanity checks should be performed using
macroexp--warn-and-return in the manner given above?

Sorry for my confusion.

Nathan

Message #14 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Tue, 05 Nov 2013 22:20:37 -0500

>> Good idea.  Could you try and use macroexp--warn-and-return instead, so
>> we get a file&line location when byte-compiling?
> I'm not certain what you mean here.  You seem to agree that this is an
> error, but `macroexp--warn-and-return' doesn't signal an error--it just
> prints a warning.  If we do something like this:

>   (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
>                      (car bindings))))
>     (macroexp--warn-and-return msg `(error "%s" ,msg)))

> we'll get a warning at compile time and an error at run time.  Is this
> what you have in mind?  Shouldn't we signal the error as early as
> possible?  Perhaps there is some Emacs convention that I'm not aware of
> in this regard.

Signaling an error stops the whole compilation, so you only get one
error at a time.  Better make it a warning, even though it is indeed
a programming error.

>> BTW, the same holds for the "let" sanity checks you added to cconv
>> (which should probably be moved to macroexp, now that I think about it,
>> so we can remove them from bytecomp.el).
> I don't understand this either.  By "moved to macroexp", do you just
> mean that the sanity checks should be performed using
> macroexp--warn-and-return in the manner given above?

No, I mean that they should be performed in macroexp--expand-all rather
than in cconv, so they're performed regardless of lexical-binding
(currently they're done once in cconv.el and once in bytecomp.el).


        Stefan

Message #17 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 06:16:55 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>   (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
>>                      (car bindings))))
>>     (macroexp--warn-and-return msg `(error "%s" ,msg)))
>
> Signaling an error stops the whole compilation, so you only get one
> error at a time.  Better make it a warning, even though it is indeed
> a programming error.

And then signal the error at run time?  Do I understand you correctly
about that?

What if we're not compiling?  If you don't want the error to abort the
build process, it seems that the ideal solution would be, in the compiled
case, to print a warning during compilation and signal an error at run
time; and in the interpreted case, to signal the error at macro
expansion time.

> No, I mean that they should be performed in macroexp--expand-all rather
> than in cconv, so they're performed regardless of lexical-binding
> (currently they're done once in cconv.el and once in bytecomp.el).

This wouldn't work since there's no guarantee that any particular form
passes through macroexp--expand-all, not in the interpreter at least.

Message #20 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 08:45:24 -0500

>>> (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
>>> (car bindings))))
>>> (macroexp--warn-and-return msg `(error "%s" ,msg)))
>> Signaling an error stops the whole compilation, so you only get one
>> error at a time.  Better make it a warning, even though it is indeed
>> a programming error.
> And then signal the error at run time?  Do I understand you correctly
> about that?

Check other uses of macroexp--warn-and-return (there aren't many).
It doesn't signal any error at all.  But they do emit warnings either
during compilation or while loading an interpreted file.

>> No, I mean that they should be performed in macroexp--expand-all rather
>> than in cconv, so they're performed regardless of lexical-binding
>> (currently they're done once in cconv.el and once in bytecomp.el).
> This wouldn't work since there's no guarantee that any particular form
> passes through macroexp--expand-all, not in the interpreter at least.

As I said, currently it's performed in bytecomp.el and cconv.el, and
there's no way to get to either of those two without going through
macroexp--expand-all first.  So, yes, there is a guarantee.

When loading an interpreted file, we go through macroexp--expand-all as
well (not not through cconv.el nor through bytecomp.el).


        Stefan

Message #23 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 20:14:37 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> (let ((msg (format "Malformed `cl-symbol-macrolet' binding: %S"
>>>> (car bindings))))
>>>> (macroexp--warn-and-return msg `(error "%s" ,msg)))
>
> Check other uses of macroexp--warn-and-return (there aren't many).
> It doesn't signal any error at all.  But they do emit warnings either
> during compilation or while loading an interpreted file.

In the example I gave, the second argument to macroexp--warn-and-return
is an (error ...) form, which will be evaluated at run time.  That's
what I meant.  If we're going to use macroexp--warn-and-return, it seems
this is the only sensible thing to do (in this case that is).  What's
the alternative?  Transform malformed let in some undefined way?  At the
very least, the behavior when compiled/evaluated should be the same as
when interpreted, i.e. an error.

But more generally, what's wrong with signalling the error at compile
time?  Sure, it would cause the Emacs build to fail, but I would call
that an advantage.  Not to mention, it's especially easy to miss the
warnings during the build process, as opposed to compiling individual
files manually.

> As I said, currently it's performed in bytecomp.el and cconv.el, and
> there's no way to get to either of those two without going through
> macroexp--expand-all first.  So, yes, there is a guarantee.
>
> When loading an interpreted file, we go through macroexp--expand-all as
> well (not not through cconv.el nor through bytecomp.el).

It doesn't look like evaluation via M-: has to go through
macroexp--expand-all.  Try:

M-:
(let ((foo 'bar)) foo)
RET

Though I guess in the specific case of malformed `let', this doesn't
really matter, since the interpreter will catch the error.

Message #26 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 21:08:39 -0500

> What's the alternative?  Transform malformed let in some undefined way?

Yup.  Just like we've done so far.

> very least, the behavior when compiled/evaluated should be the same as
> when interpreted, i.e. an error.

For incorrect syntax, it's perfectly OK to misbehave differently in the
two cases.  Especially, the interpreted case without going through eager
macroexpansion (i.e. through macroexpand-all) is largely irrelevant.

> But more generally, what's wrong with signalling the error at compile
> time?

I explained that already: the first error stops everything, so you only
get one error report even when there are several errors.

>> When loading an interpreted file, we go through macroexp--expand-all as
>> well (not not through cconv.el nor through bytecomp.el).
> It doesn't look like evaluation via M-: has to go through
> macroexp--expand-all.

No, because M-: is not "loading an interpreted file".
But sooner or later M-: will also go through macroexpand-all.


        Stefan

Message #29 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 22:22:30 -0500

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> What's the alternative?  Transform malformed let in some undefined way?
>
> Yup.  Just like we've done so far.

I think I understand what you want.  This patch uses
macroexp--warn-and-return.  I'll try to move the checks in
bytecomp.el/cconv.el later.

Nathan

[cl-macs.el.patch (text/x-diff, inline)]

From 3843a58d0ebcaea9e6c9446ca6b6f52611c8097d Mon Sep 17 00:00:00 2001
From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Date: Tue, 5 Nov 2013 14:36:32 -0500
Subject: [PATCH] Print warning for malformed bindings in cl-symbol-macrolet.

---
 lisp/ChangeLog             |  5 +++++
 lisp/emacs-lisp/cl-macs.el | 18 +++++++++++++-----
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 828fcda..824e73c 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2013-11-05  Nathan Trapuzzano  <nbtrap <at> nbtrap.com>
+
+	* emacs-lisp/cl-macs.el (cl-symbol-macrolet): Print warning for
+	malformed bindings form.
+
 2013-11-05  Eli Zaretskii  <eliz <at> gnu.org>
 
 	* international/quail.el (quail-help): Be more explicit about the
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 60fdc09..9cdde5e 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -1992,11 +1992,19 @@ by EXPANSION, and (setq NAME ...) will act like (setf EXPANSION ...).
       (unwind-protect
           (progn
             (fset 'macroexpand #'cl--sm-macroexpand)
-            ;; FIXME: For N bindings, this will traverse `body' N times!
-            (macroexpand-all (cons 'progn body)
-                             (cons (list (symbol-name (caar bindings))
-                                         (cl-cadar bindings))
-                                   macroexpand-all-environment)))
+            (let ((expansion
+                   ;; FIXME: For N bindings, this will traverse `body'
+                   ;; N times!
+                   (macroexpand-all (cons 'progn body)
+                                    (cons (list (symbol-name (caar bindings))
+                                                (cl-cadar bindings))
+                                          macroexpand-all-environment))))
+              (if (or (null (cdar bindings)) (cl-cddar bindings))
+                  (macroexp--warn-and-return
+                   (format "Malformed `cl-symbol-macrolet' binding: %S"
+                           (car bindings))
+                   expansion)
+                expansion)))
         (fset 'macroexpand previous-macroexpand))))))
 
 ;;; Multiple values.
-- 
1.8.4.2

Message #34 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Wed, 06 Nov 2013 23:38:33 -0500

> I think I understand what you want.  This patch uses
> macroexp--warn-and-return.

Perfect.  Installed.

> I'll try to move the checks in bytecomp.el/cconv.el later.

Thanks, no hurry.


        Stefan

Message #37 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 15814 <at> debbugs.gnu.org
Subject: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Wed, 06 Nov 2013 23:08:42 -0800

Unfortunately that patch seems to have broken 'make bootstrap'.
The problem first appeared in trunk bzr 115013.

Here are the symptoms:

Compiling progmodes/cc-cmds.el

In toplevel form:
progmodes/cc-cmds.el:4624:1:Error: Invalid function: (--dolist-tail-- ad-advice-classes)
Makefile:267: recipe for target 'progmodes/cc-cmds.elc' failed
make[2]: *** [progmodes/cc-cmds.elc] Error 1
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
Makefile:295: recipe for target 'compile-main' failed
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
Makefile:378: recipe for target 'lisp' failed
make: *** [lisp] Error 2

Message #40 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Thu, 07 Nov 2013 07:58:32 -0500

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Unfortunately that patch seems to have broken 'make bootstrap'.
> The problem first appeared in trunk bzr 115013.

It looks like the offending change from that patch was the line in the
cl--block-wrapper definition.  I'm not sure if Stefan meant to include
that line or just forgot to clean his directory before intsalling the
patch.

Either way, it's not really clear why it broke anything.  The only thing
I can think of is macroexp-progn assumes its argument satisfies listp
and calls cdr on it, which would cause a compile-time error.  Whereas
without the patch, there would have been (progn . ATOM), an error that
wouldn't have been detected at build time (so far as I know).

Message #43 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Thu, 07 Nov 2013 14:46:10 -0500

> It looks like the offending change from that patch was the line in the
> cl--block-wrapper definition.  I'm not sure if Stefan meant to include
> that line or just forgot to clean his directory before intsalling the
> patch.

My directories are never clean, so I regularly fall into this trap.
Should be fixed now,


        Stefan

Message #46 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Thu, 07 Nov 2013 14:51:33 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I'll try to move the checks in bytecomp.el/cconv.el later.
>
> Thanks, no hurry.

Do you want all of the syntactial sanity checks moved, or just let/let*?

Message #49 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Nathan Trapuzzano <nbtrap <at> nbtrap.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Thu, 07 Nov 2013 16:03:12 -0500

Stefan Monnier wrote:

>> It looks like the offending change from that patch was the line in the
>> cl--block-wrapper definition.  I'm not sure if Stefan meant to include
>> that line or just forgot to clean his directory before intsalling the
>> patch.
>
> My directories are never clean, so I regularly fall into this trap.

This is a problem, isn't it? I mean, what happens when you accidentally
commit something that causes a non-obvious problem?

For example, in the course of bisecting something today, I came across
r112851, http://lists.gnu.org/archive/html/emacs-diffs/2013-06/msg00043.html,
which seems to include an unrelated change to subr.el that has no
ChangeLog entry AFAICS.

Message #52 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Nathan Trapuzzano <nbtrap <at> nbtrap.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Thu, 07 Nov 2013 17:07:30 -0500

PS I find what works for me is to have several local branches in
various degress of messiness, but to try to keep a pristine one from
which to commit patches (especially ones from other people).

Message #55 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Thu, 07 Nov 2013 20:21:48 -0500

>>> I'll try to move the checks in bytecomp.el/cconv.el later.
>> Thanks, no hurry.
> Do you want all of the syntactial sanity checks moved, or just let/let*?

Are there others in cconv.el?


        Stefan

Message #58 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Thu, 07 Nov 2013 20:29:37 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Are there others in cconv.el?

Don't think so, but I'm talking about the ones byte*.el in addition to
cconv.el.  E.g. in byte-optimize-form-code-walker.

Message #61 received at 15814 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Nathan Trapuzzano <nbtrap <at> nbtrap.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 15814 <at> debbugs.gnu.org
Subject: Re: bug#15814: bootstrap fails due to recent cl-symbol-macrolet patch
Date: Thu, 07 Nov 2013 20:34:17 -0500

> PS I find what works for me is to have several local branches in
> various degress of messiness, but to try to keep a pristine one from
> which to commit patches (especially ones from other people).

That's also what I try to do, but it's still littered with things that are
"about to be installed" (like the macroexp-progn that introduced this
bug, or the add-to-list compiler-macro of http://lists.gnu.org/archive/html/emacs-diffs/2013-06/msg00043.html).


        Stefan

Message #64 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Thu, 07 Nov 2013 22:02:56 -0500

>> Are there others in cconv.el?
> Don't think so, but I'm talking about the ones byte*.el in addition to
> cconv.el.  E.g. in byte-optimize-form-code-walker.

I think they're OK there for now.
Now that I think about it, maybe an alternative for the "let format
checks" is to keep them in bytecomp.el and change cconv so that the
problems are *preserved* (and hence later detected by bytecomp).


        Stefan

Message #67 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Fri, 08 Nov 2013 06:40:10 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Now that I think about it, maybe an alternative for the "let format
> checks" is to keep them in bytecomp.el and change cconv so that the
> problems are *preserved* (and hence later detected by bytecomp).

I thought the point of moving them to macroexp was so the checks happen
even when we're not compiling.

Message #70 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Fri, 08 Nov 2013 08:33:55 -0500

>> Now that I think about it, maybe an alternative for the "let format
>> checks" is to keep them in bytecomp.el and change cconv so that the
>> problems are *preserved* (and hence later detected by bytecomp).
> I thought the point of moving them to macroexp was so the checks happen
> even when we're not compiling.

No, the point was mainly to consolidate the checks from 2 places to
a single place.  If people don't compile their code, they get very
little feedback about the quality of their code, and I don't think it's
important to change this state of affair.

macroexp--warn* is handy when you need it (e.g. in cl-symbol-macrolet),
but it's a hack, so if we don't need to use it, better.


        Stefan

Message #73 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Fri, 08 Nov 2013 09:39:06 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Now that I think about it, maybe an alternative for the "let format
>>> checks" is to keep them in bytecomp.el and change cconv so that the
>>> problems are *preserved* (and hence later detected by bytecomp).

We can make cconv work while preserving the malformed bindings, but when
the compiler prints the warnings, there's a good chance that the
malformed binding that gets printed will not look like the binding as it
appears in the source, since cconv might transform the VALUE part.
Therefore I think it's preferable to use byte-compile-log-warning in
cconv.

Message #76 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Fri, 08 Nov 2013 14:06:48 -0500

>>>> Now that I think about it, maybe an alternative for the "let format
>>>> checks" is to keep them in bytecomp.el and change cconv so that the
>>>> problems are *preserved* (and hence later detected by bytecomp).
> We can make cconv work while preserving the malformed bindings, but when
> the compiler prints the warnings, there's a good chance that the
> malformed binding that gets printed will not look like the binding as it
> appears in the source, since cconv might transform the VALUE part.
> Therefore I think it's preferable to use byte-compile-log-warning in
> cconv.

OK, fair enough,


        Stefan

Message #79 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Fri, 08 Nov 2013 21:06:34 -0500

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> We can make cconv work while preserving the malformed bindings, but when
>> the compiler prints the warnings, there's a good chance that the
>> malformed binding that gets printed will not look like the binding as it
>> appears in the source, since cconv might transform the VALUE part.
>> Therefore I think it's preferable to use byte-compile-log-warning in
>> cconv.
>
> OK, fair enough,

[cconv.el.patch (text/x-diff, inline)]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: nbtrap <at> nbtrap.com-20131109010452-m4od51q5sllj5llv
# target_branch: file:///home/nathan/opt/etc/bzr-repos/emacs/trunk/
# testament_sha1: a475ad3ca1826fb0b56abf8dfb460185dd5fd144
# timestamp: 2013-11-08 20:28:15 -0500
# base_revision_id: dgutov <at> yandex.ru-20131108112252-g8bofo4jray5k45v
# 
# Begin patch
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2013-11-08 11:22:52 +0000
+++ lisp/ChangeLog	2013-11-09 01:04:52 +0000
@@ -1,3 +1,8 @@
+2013-11-09  Nathan Trapuzzano  <nbtrap <at> nbtrap.com>
+
+	* emacs-lisp/cconv.el (cconv-convert): Print warning instead of
+	throwing error over malrofmed let/let*.
+
 2013-11-08  Dmitry Gutov  <dgutov <at> yandex.ru>
 
 	* progmodes/ruby-mode.el (ruby-smie--indent-to-stmt): Use

=== modified file 'lisp/emacs-lisp/cconv.el'
--- lisp/emacs-lisp/cconv.el	2013-11-04 19:48:07 +0000
+++ lisp/emacs-lisp/cconv.el	2013-11-08 16:50:27 +0000
@@ -291,9 +291,9 @@
          (let* ((value nil)
 		(var (if (not (consp binder))
 			 (prog1 binder (setq binder (list binder)))
-		       (cl-assert (null (cdr (cdr binder))) nil
-				  "malformed let binding: `%s'"
-                                  (prin1-to-string binder))
+                       (when (cddr binder)
+                         (byte-compile-log-warning
+                          (format "Malformed `%S' binding: %S" letsym binder)))
 		       (setq value (cadr binder))
 		       (car binder)))
 		(new-val

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWRnlTkQABHp/gACwCwBS9///
XidMAP////BgCA+8Z97xsBoDebjpkOglRp2BKQU9UfqnpMI0PU/RTxGmoNMQDI0yaYAJJEYIGgFP
U1GUZPU0MjQ0AABoOaYmTJowmCYmmATAIYIwIwCRTKTCnio9TyjRmmmo8k9Q0aA0Ho1D1DQEVJqY
1TGUaPUaZGgPUGjQAAAACKSNAJonpT0wQk/KZpqbSTTTEAaBo9RyIxPii2QhWaJaTPGncduwU8JV
tiNejlnkn5/tvMJdOQlOOpSuAb3NjlYVVPCUSpJknRSakAoE03Ty47/u+HblepbjEaTGDr3iuhVg
+PwkDIKposzzzxhBQczVnzJmW8O3DeZPBofIejbkpNvikmzmIX9/fCigsKsclOqZXLk6K8IJURVK
oSssX65FBc9N8i4psuFhFEprxi9LHy0z56llkdMTTo6nvpfX9wGucy8pERWmxJiahjUYTHVuIWet
qMIJ6KXNc3hHvMSSm5K4UVgwoMHdyHKGwGNwMwlxtoiMxmdpLeJxmCKGa7hudG9/lgS12QlJLkPX
8CsrKFy1wwc5znO8CJMQdlFDjO5M7vkFYTLBlQqwFW4sPfSbUPESeqVNiQMc/KuduONgShQqn86B
pSjG2SFK4mcotzkZrWt3BeX9Q565LXMws82kPugaIGEXeOniyrFaksC9JIUsmqecNKN65oz3Yyzm
hVnTwSt4oMgxLJiOyxUw0UkWoKR+uagB5RJSqlnQWC0rV+4/a2JQ7vTEXec5wIj7C0HCGE0n6IPc
wkrEdzVpr2KBTYgwwRwaI9gyP8LTWDkG+2NMQvvcZ8PEXQLBcMOhGjLSVatY8SVIGIjaxGvYl1sS
drtIyOovU8sGgGy3HwWOqwVhjO6K2tyyJnuERQPnohhFut/F6DCMUO3ObSNXJFqLAoDhYBu/Syb+
wUhyPCLJigtBOwKmw1kfQHMaQ2FZEBpQyikuGwJjelxBozaqaiYZSIUIc0LJFeTgmOPeiMvhD3is
FujMMDFsRx35VaDujRgiOQNsdecqXmu1z58LblhY8kayhkr3q+TCHVGZoka0hoPtucYyRS5yxWKD
IiWJ843Xo+QO5A4MS9F2HQyMqIsvckG8zMhiaVWphALaXi0L7t7wgobJifpDdw/xz4lnbvCDuD5S
u7OIoao8V9XCZrjEHUdJrM3EDmxcDG5Q8VuoiGVKxpkee4OR5lB5kc+yeC0SrPpZWDLAW4Wpk1LQ
zLcEoYoQaGE4yEpoYPWnMlo4Qyuq8Q2zQL0ttvZpW5UW31IS6QsvQ0DGfjXa4lkYkg9wwld5Yqgj
16pFUbbbcuisFbrK/KynUHgDpegmdh5Ms/72mnPSgVm6my6EdTa3+5q5okEcuoLXWeIUBoCkVcDX
1KyOgWYJm+oSbi0LhPPI1nX9ntQ8TeXITPDnPndNu7skOt7Q7neIuxPp3ozsMDT005yiCo++G3HM
wc+RBBqmR0+WJk7MpWRb9SLU89ZWZRYkm8VPCkYkJsWHgceLWoKcDT8B2FV63IV1X0srELdva7Sc
dU98iJ77W+B2aws5DSHEMDF01J8Q+BxYYOPI5FHOCmcNPlRUQ7966PVxPq3j1QjCMWZ0uxt6ik7K
Ha2hBcrJb4izTlcZphGEy011nVgtPHF9yM/BYo3CW271ipb9608k1221ssCT3S9X0aRtMOXiayWs
cEJSElsLmUbbH199kyo4NLNtdo3CSB1BYFAlyHyEqeLq2fJLPsknI3VGvtPXNOYTLqOwkSqkWNPj
eRMYT2F+ofcJ/D3vY6dkBI6QHk7ghkTnCQGAeoKNyDYqDEdNB40OQNJszKUDgFYHAgwLEEgY9CRk
JqZBwc0YOh9EIZTZjPQhsR9kDBMcXLgJ0QxvzwYRDXg7dzk2PbmNYP928ge1JeDsqaVxDwDftE7w
k9Ym8TsEo8wv9ZBEBEA4A4MgdxWxCHvdDmY5CWh0uJ7qbx2Mx4OQ4lldaFHZ4eCDUMBS4hMCtYfZ
G3udIqJ2KMK1QUK2qQcENCdLUaEJZzMOxDKDoDKDpzharhliSYMLliXEASDOhBK4ZwrqDikiv6w6
FaJSEkLJCCMrA6+JdSF6NQoxT0B3HkXOkBedzBexcsjYBYF7wEdeFKPtpQyqkE9NGT1osXskWe5h
hCgbGG3bMJvArDihsTmP4CU8zDPRKJAyE2vUIvoHzDO0Vq1enUaHm5DUYeVlZZJGYb7u2ut2fEuA
n9oST0z0HtKc3t4UPTLzrMuWrLYdBhmTZq8FDY7IYgiLzzG6oLmIcxcJSxXPEn6RjGe1kykzaHeM
33SZE2dreOtrQpChD+ZOq9xHQVF4SpCwMgizEWFMEK8DJyk4QbJnOv9CFr3sX7LzHYPqcHIZiTUD
zGwdkZLkcEIoIjG4KqCiBwewNr7w8mn3I4RcwTCoMkHrDNLJlmHX0g4Rxdkgf8wUEeISBy7B/4u5
IpwoSAzypyIA

Message #82 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Sat, 09 Nov 2013 09:36:26 +0100

Nathan Trapuzzano <nbtrap <at> nbtrap.com> writes:

> +	* emacs-lisp/cconv.el (cconv-convert): Print warning instead of
> +	throwing error over malrofmed let/let*.

s/malrofmed/malformed/

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #85 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Sat, 09 Nov 2013 07:00:38 -0500

[Message part 1 (text/plain, inline)]

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> +	* emacs-lisp/cconv.el (cconv-convert): Print warning instead of
>> +	throwing error over malrofmed let/let*.
>
> s/malrofmed/malformed/

Thanks.

[fixed-cconv.el.patch (text/x-diff, inline)]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: nbtrap <at> nbtrap.com-20131109115727-jhn9e1k2ua493zox
# target_branch: file:///home/nathan/opt/etc/bzr-repos/emacs/trunk/
# testament_sha1: 73a49428b51bbcbec941aab9e1b5eec802a8ab58
# timestamp: 2013-11-09 06:58:55 -0500
# base_revision_id: dgutov <at> yandex.ru-20131108112252-g8bofo4jray5k45v
# 
# Begin patch
=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2013-11-08 11:22:52 +0000
+++ lisp/ChangeLog	2013-11-09 11:57:27 +0000
@@ -1,3 +1,8 @@
+2013-11-09  Nathan Trapuzzano  <nbtrap <at> nbtrap.com>
+
+	* emacs-lisp/cconv.el (cconv-convert): Print warning instead of
+	throwing error over malformed let/let*.
+
 2013-11-08  Dmitry Gutov  <dgutov <at> yandex.ru>
 
 	* progmodes/ruby-mode.el (ruby-smie--indent-to-stmt): Use

=== modified file 'lisp/emacs-lisp/cconv.el'
--- lisp/emacs-lisp/cconv.el	2013-11-04 19:48:07 +0000
+++ lisp/emacs-lisp/cconv.el	2013-11-08 16:50:27 +0000
@@ -291,9 +291,9 @@
          (let* ((value nil)
 		(var (if (not (consp binder))
 			 (prog1 binder (setq binder (list binder)))
-		       (cl-assert (null (cdr (cdr binder))) nil
-				  "malformed let binding: `%s'"
-                                  (prin1-to-string binder))
+                       (when (cddr binder)
+                         (byte-compile-log-warning
+                          (format "Malformed `%S' binding: %S" letsym binder)))
 		       (setq value (cadr binder))
 		       (car binder)))
 		(new-val

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWfliC0cABdr/gACwCwBS9///
XydMAP////BgCc+KkAAAAAAAAAAABKUzU9RT1GTT1APNSP1Q09QGnqAA0yaNNqDmjJiYAJiMCNMC
DEYJkwCMOaMmJgAmIwI0wIMRgmTAIw5oyYmACYjAjTAgxGCZMAjDmjJiYAJiMCNMCDEYJkwCMCqI
gAgCaNBDQaE9Q0mSaPUPKaNo1GRHhT4xpKqoTSgUo3zvoxRoNIr9VDC5nTmjNNGEb/62ZjzvmVFs
8ERfIZmmzjNuCVx50mlq2KG6yOyAqhyyt4e/9//J/+/bfPuP+o2RMEpTMTf+8GVS9EujmqlVbYpH
GeVlOhMXVUttut5cSW/RDLezDUwkqOjnZy6m4os+FHhd+/jgeTkt9nWqoVtZrhNVhWttkUiw3109
9gqyny0sGdmGShnn8KW5Cuzvo4DFHLYOMAxEicQNi5tjjovHgISyzTKckgISZ9eHYqFshjLbLivB
uqjytO2Qdw7e0G9cGMIBpDWHttPWIEnv8X4HkdTeeaKoWnwvqhR6nuF31OrfWD1ynpnW/T7rL/ls
U5cxDGI7TD2lm7C67M4660pSlKUpTyYRkI7yamxbmNp30Ly1ghSsEJLurB8vxtdYKoW86WYCUJyf
P64XZbGzEpMQWXT/WqFglFduNIKzEwbWauO1OuJea9Tfq1oL7ZpBfa0w9Sw+0orKExEFneOPmYbB
DUci/AVRS8wNV1xxrnZwtyrgnEpdBC0f8RGw49maSNpblEPA2n9MzkjRGUL4O1XG/IvHxwY48IOi
eWY2lOfKrjNL09ltzJ3e+5F6HF2t9b2CxasKIShONeBH5yIWDuncyce5kZcl0pNcJmt6yTc/hc28
cLUWQc+G3HPaa60cOysIv1pN600So7KKfmjHKdVI5MtcpsqIZ3G1DfYOXgw2OvJzZV52Ytzr0wsh
m37cFMDodFbzTipv7GqbS1S5u0v2Yxjvv37WTsQwg0RZZpyN6cqoWc6bum0jfhaKZty0v30ItFiM
iiG053Wcc+yq/OneaY7UXrDGYmSWo5Cm1c3psv9580LDkvJk3Qcc6cFzRCuRehcaWMKtEm/s4buL
suRf01VLaMc192xZtYtmrcyUf6GGPuP9IWIdg5Gxtnao67d87L68nPlQxW1golyd3ipdwpLXYnTn
hnbl0OeyRi27b+jHfXBWbTZZDZEYTBdNW5VSk4MEUTuyvzVXYXVbMIZM8Kmw2EZbmK2LLMNNR8zt
goZtEZ7tnclG/OFut1UOcwTk4OOG4v3lidbi2rK7RGfBOLPhy1MTDkS14e8wqyt9nDs35zblddTs
T9G/jNF4nfFUNd9IiJnNtKUbViMrcZt4UWujpaYRLpgpHRo9h0MoiJOF836b+PxRTy2HVVxwq4uv
rntOyDhjTkb6RJqO0tJJvLikFkRFxUiS4m0YQi+4k/SH4w+I6w+h1M0pS8h0mZmZn4ew/Uoen1EP
Uw0iJiEzMx+/sxTWbKRXYshP6phYbTYUhHr7bBa+OOO/wvD2Mvf4zj7vsiiv4lrTSju912zy1bXk
sbVnw/n7Onh5Re57866R3HlCPLKbf8ZGk3rkeB3wxPB8ysRvhZCENG7eQo9TDRGv8QoZMTJD7+Du
dO/7oPD6vJnBc6+V131zujP6+L284O6ND2HiEOo/b0gW4Mtjn58OdtjgmWEfnMZ7tpL6/FKXS1OX
z3bnE9uLFzqa7BDYfba2vpERVhGbZHaitU069vod9uzj4dcVvAt/JDuX6waEX3a2FMCMeucdzZdT
hd30Td35RpKN+fQx+QtPM1bTlcPzPyecSS8/k+SvzlZbMWfWtyTs746+kzh0nrbXpKPS6++y+ZpG
Ha5ejLGzJ3zbk8V8dpuOzbHCSYmhpHAmEbMlzly4suEwubNtdBw8jaOcMObOpsMObn1OPxiMMsvX
ErsaVM/ZZ2fsWjQ2+nzdyncNpFKQijqyik9+B7fjgtXPMsi0xjvGUIoHaYFUMiP0QuPfHTv6v0hj
50h6Oq32YL+6r3Xj6FzOvivVVvoxi356ptEj4xh2D8EP3PkeJy7pKPWYfcd8JKLbZRMRocivfB2l
ImEetCdlHceT4cSyCahhD+8VNWEFg2er70VjjCOwpDzjZOpvP5IkpaWi3fB3Ij4SJWjbHHzhH4Qb
M9yWkzF+kde84mB5au0P/cfQPJFPkf47ry2IbTtR6HjqiqHyKnRDwhHkhX8DT3JTJMhqGpQO9eTM
Q/I4GpPzQxh97Jb32Zodxah5nBDYYX3oivj6ekQLkJhZGyFqF4mPhLv9hxFCcCut5QVjG2yE1VmD
70SKVyR7BDm5JxhKiaEqJpCVE090MjNLBBJJkbWSsFkRL5wWHv3F90PgKL/4mNxCtKQikRFCJTxw
h0+L0ztNB70K7YnyP8x3w90RENX+ZD7HjYmYGENJbIR/bSwNthHC6ha41ZI4HYIToUELupJJFRiT
Hsz63Fx5sIe+DuHoh+iFn0a71aJpCKQjqcQh/MPwNsVvIXfzvbj6HAXNPuwvYUC08MvK+86vpGSG
P9jCKxNSPsy6aT7cnww8jezOMxyUulKYTvNAkwjtmJlMxM5vVDK6GRMmrKEWRN9uxb/M7J24lClC
0qd4tPZQotLcTMdC+CyFYP7qHPM2DcuZwjUjkeIQorE3yRs3mEYfQuJP6o51jPX84Pkd8tnOPF4H
9KQ7TjEROR4t54DbHauqmZTN5F8S7A3QZQUPvOemh8pxdw7BnV3SqZFN5NEQ9ThBuk4GH5FEOzs1
3QWfWGaHtMYUPojwh/+LuSKcKEh8sQWjgA==

Message #88 received at 15814-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nathan Trapuzzano <nbtrap <at> nbtrap.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 15814-done <at> debbugs.gnu.org
Subject: Re: bug#15814: 24.3.50;
 Signal error on malformed bindings in `cl-symbol-macrolet' (patch)
Date: Sun, 10 Nov 2013 23:55:59 -0500

> Thanks.

Installed,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.