GNU bug report logs -
#27718
26.0.50; (cl-typep instance-ab 'class-a) gives wrong answer when compiled
Previous Next
Reported by: npostavs <at> users.sourceforge.net
Date: Sat, 15 Jul 2017 21:50:01 UTC
Severity: normal
Tags: fixed, patch
Found in version 26.0.50
Fixed in version 26.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27718 in the body.
You can then email your comments to 27718 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
agrambot <at> gmail.com, bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Sat, 15 Jul 2017 21:50:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
npostavs <at> users.sourceforge.net
:
New bug report received and forwarded. Copy sent to
agrambot <at> gmail.com, bug-gnu-emacs <at> gnu.org
.
(Sat, 15 Jul 2017 21:50:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
~/src/emacs$ .../emacs -Q -batch -f batch-byte-compile cl-typep-subclass.el
~/src/emacs$ .../emacs -Q -batch -l cl-typep-subclass.el
(cl-typep eitest-ab ’class-a) => t
~/src/emacs$ .../emacs -Q -batch -l cl-typep-subclass.elc
(cl-typep eitest-ab ’class-a) => nil
Where cl-typep-subclass.el is
[cl-typep-subclass.el (text/plain, inline)]
(require 'eieio)
(require 'eieio-base)
(require 'eieio-opt)
(eval-when-compile (require 'cl-lib))
(defclass class-a ()
()
"Class A")
(defclass class-b ()
()
"Class B")
(defclass class-ab (class-a class-b)
()
"Class A and B combined.")
(defvar eitest-ab nil)
(setq eitest-ab (class-ab))
(message "(cl-typep eitest-ab 'class-a) => %S" (cl-typep eitest-ab 'class-a))
[Message part 3 (text/plain, inline)]
This test case is a reduction from
test/lisp/emacs-lisp/eieio-tests/eieio-tests.el. You can see that tests
23 and 24 will fail when you do 'make eieio-tests TEST_LOAD_EL=no'.
In GNU Emacs 26.0.50 (build 64, x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2017-07-15 built on zony
Repository revision: b30ee0c9225bad6e3fd0b511a6c5d9a64b8fd66a
Windowing system distributor 'The X.Org Foundation', version 11.0.11901000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --cache-file=../debug-config.cache 'CFLAGS=-O0 -g3
-march=native' --enable-checking=yes,glyphs
--enable-check-lisp-object-type MAKEINFO=makeinfo-4.13a
--with-x-toolkit=lucid --with-toolkit-scroll-bars --with-gif=no
--with-jpeg=no'
Configured features:
XPM TIFF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 LIBSYSTEMD
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Fri, 21 Jul 2017 12:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 27718 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tags 27718 + patch
quit
npostavs <at> users.sourceforge.net writes:
> ~/src/emacs$ .../emacs -Q -batch -f batch-byte-compile cl-typep-subclass.el
> ~/src/emacs$ .../emacs -Q -batch -l cl-typep-subclass.el
> (cl-typep eitest-ab ’class-a) => t
> ~/src/emacs$ .../emacs -Q -batch -l cl-typep-subclass.elc
> (cl-typep eitest-ab ’class-a) => nil
lisp/emacs-lisp/eieio.el:260:
(defmacro defclass (name superclasses slots &rest options-and-doc)
...
;; When using typep, (typep OBJ 'myclass) returns t for objects which
;; are subclasses of myclass. For our predicates, however, it is
;; important for EIEIO to be backwards compatible, where
;; myobject-p, and myobject-child-p are different.
;; "cl" uses this technique to specify symbols with specific typep
;; test, so we can let typep have the CLOS documented behavior
;; while keeping our above predicate clean.
(put ',name 'cl-deftype-satisfies #',testsym2)
The problem is that the `put' doesn't take effect until runtime, so the
compiler inlines `cl-typep' incorrectly. Using `function-put' here (and
`function-get' in `cl-typep') solves it (requires also the patches for
#27016[1]), although it seems a bit coincidental that `class-a' happens
to be a function as well, so I'm not sure if this is the right thing.
Stefan, any thoughts?
[v1-0001-Fix-cl-typep-instance-ab-class-a-compilation-Bug-.patch (text/x-diff, inline)]
From 4ea34c9da04c8eabc754f2ca64ef4e2ac7c59cac Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Fri, 21 Jul 2017 07:59:21 -0400
Subject: [PATCH v1] Fix (cl-typep instance-ab 'class-a) compilation
(Bug#27718)
Using `function-put' instead of `put' for the `cl-deftype-satisfies'
property lets the compiler know about it while compiling the file so
that any calls to `cl-typep' will be inlined correctly.
* lisp/emacs-lisp/eieio.el (defclass): Use `function-put' for the
`cl-deftype-satisfies' property.
* lisp/emacs-lisp/cl-macs.el (cl-typep): Also use `function-get' to
check the 'cl-deftype-satisfies' property.
---
lisp/emacs-lisp/cl-macs.el | 7 +++++--
lisp/emacs-lisp/eieio.el | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 451e6490d7..f5a4f99aad 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -2991,8 +2991,11 @@ (define-inline cl-typep (val type)
((and (pred symbolp) type (guard (get type 'cl-deftype-handler)))
(inline-quote
(cl-typep ,val ',(funcall (get type 'cl-deftype-handler)))))
- ((and (pred symbolp) type (guard (get type 'cl-deftype-satisfies)))
- (inline-quote (funcall #',(get type 'cl-deftype-satisfies) ,val)))
+ ((and (pred symbolp) type (guard (or (function-get type 'cl-deftype-satisfies)
+ (get type 'cl-deftype-satisfies))))
+ (inline-quote (funcall #',(or (function-get type 'cl-deftype-satisfies)
+ (Get type 'cl-deftype-satisfies))
+ ,val)))
((and (or 'nil 't) type) (inline-quote ',type))
((and (pred symbolp) type)
(let* ((name (symbol-name type))
diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
index 1a7de55fce..2c333c16f4 100644
--- a/lisp/emacs-lisp/eieio.el
+++ b/lisp/emacs-lisp/eieio.el
@@ -246,7 +246,7 @@ (defmacro defclass (name superclasses slots &rest options-and-doc)
;; test, so we can let typep have the CLOS documented behavior
;; while keeping our above predicate clean.
- (put ',name 'cl-deftype-satisfies #',testsym2)
+ (function-put ',name 'cl-deftype-satisfies #',testsym2)
(eieio-defclass-internal ',name ',superclasses ',slots ',options-and-doc)
--
2.11.1
[Message part 3 (text/plain, inline)]
> You can see that tests 23 and 24 will fail when you do 'make
> eieio-tests TEST_LOAD_EL=no'.
This actually isn't true until the patch for #24402[2] is applied.
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27016#140
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24402#71
Added tag(s) patch.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 21 Jul 2017 12:22:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Fri, 21 Jul 2017 13:21:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 27718 <at> debbugs.gnu.org (full text, mbox):
> The problem is that the `put' doesn't take effect until runtime, so the
> compiler inlines `cl-typep' incorrectly. Using `function-put' here (and
> `function-get' in `cl-typep') solves it (requires also the patches for
> #27016[1]), although it seems a bit coincidental that `class-a' happens
> to be a function as well, so I'm not sure if this is the right thing.
> Stefan, any thoughts?
Hmm... I agree that using the same approach as that of bug#27016 is
right, but indeed `name` doesn't refer to a function but to the name of
a type (the property doesn't apply to the value stored in the
symbol-function cell and shouldn't follow alias definitions).
So maybe rather than hijack function-get/put in bug#27016, we should
introduce a new "definitional put" with a corresponding `get`, and then
use that here as well as in function-put/get.
Maybe we could simply change put&get directly without introducing
yet-another slightly different get/put?
Stefan
> From 4ea34c9da04c8eabc754f2ca64ef4e2ac7c59cac Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Fri, 21 Jul 2017 07:59:21 -0400
> Subject: [PATCH v1] Fix (cl-typep instance-ab 'class-a) compilation
> (Bug#27718)
> Using `function-put' instead of `put' for the `cl-deftype-satisfies'
> property lets the compiler know about it while compiling the file so
> that any calls to `cl-typep' will be inlined correctly.
> * lisp/emacs-lisp/eieio.el (defclass): Use `function-put' for the
> `cl-deftype-satisfies' property.
> * lisp/emacs-lisp/cl-macs.el (cl-typep): Also use `function-get' to
> check the 'cl-deftype-satisfies' property.
> ---
> lisp/emacs-lisp/cl-macs.el | 7 +++++--
> lisp/emacs-lisp/eieio.el | 2 +-
> 2 files changed, 6 insertions(+), 3 deletions(-)
> diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
> index 451e6490d7..f5a4f99aad 100644
> --- a/lisp/emacs-lisp/cl-macs.el
> +++ b/lisp/emacs-lisp/cl-macs.el
> @@ -2991,8 +2991,11 @@ (define-inline cl-typep (val type)
> ((and (pred symbolp) type (guard (get type 'cl-deftype-handler)))
> (inline-quote
> (cl-typep ,val ',(funcall (get type 'cl-deftype-handler)))))
> - ((and (pred symbolp) type (guard (get type 'cl-deftype-satisfies)))
> - (inline-quote (funcall #',(get type 'cl-deftype-satisfies) ,val)))
> + ((and (pred symbolp) type (guard (or (function-get type 'cl-deftype-satisfies)
> + (get type 'cl-deftype-satisfies))))
> + (inline-quote (funcall #',(or (function-get type 'cl-deftype-satisfies)
> + (Get type 'cl-deftype-satisfies))
> + ,val)))
> ((and (or 'nil 't) type) (inline-quote ',type))
> ((and (pred symbolp) type)
> (let* ((name (symbol-name type))
> diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
> index 1a7de55fce..2c333c16f4 100644
> --- a/lisp/emacs-lisp/eieio.el
> +++ b/lisp/emacs-lisp/eieio.el
> @@ -246,7 +246,7 @@ (defmacro defclass (name superclasses slots &rest options-and-doc)
> ;; test, so we can let typep have the CLOS documented behavior
> ;; while keeping our above predicate clean.
> - (put ',name 'cl-deftype-satisfies #',testsym2)
> + (function-put ',name 'cl-deftype-satisfies #',testsym2)
> (eieio-defclass-internal ',name ',superclasses ',slots ',options-and-doc)
> --
> 2.11.1
>> You can see that tests 23 and 24 will fail when you do 'make
>> eieio-tests TEST_LOAD_EL=no'.
> This actually isn't true until the patch for #24402[2] is applied.
> [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27016#140
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24402#71
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Sat, 22 Jul 2017 17:50:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 27718 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> So maybe rather than hijack function-get/put in bug#27016, we should
> introduce a new "definitional put" with a corresponding `get`, and then
> use that here as well as in function-put/get.
>
> Maybe we could simply change put&get directly without introducing
> yet-another slightly different get/put?
Something like this?
[0001-Let-put-take-effect-during-compilation-Bug-27718.patch (text/x-diff, inline)]
From 7645c7ff5078aa0bc937969fb1550b0f794d793e Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Sat, 22 Jul 2017 13:46:58 -0400
Subject: [PATCH] Let `put' take effect during compilation (Bug#27718)
* lisp/emacs-lisp/bytecomp.el: Use `byte-compile-function-put' to
handle `put' as well.
* src/fns.c (Fget): Consult `byte-compile-plist-environment'.
* lisp/subr.el (function-get): Let `get' take care of consuling
`byte-compile-plist-environment'.
---
lisp/emacs-lisp/bytecomp.el | 1 +
lisp/subr.el | 7 +------
src/fns.c | 10 ++++++++++
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 4dda3bdc2b..3fead4229e 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -4719,6 +4719,7 @@ (defun byte-compile-form-make-variable-buffer-local (form)
(byte-compile-keep-pending form 'byte-compile-normal-call))
(put 'function-put 'byte-hunk-handler 'byte-compile-function-put)
+(put 'put 'byte-hunk-handler 'byte-compile-function-put)
(defun byte-compile-function-put (form)
(pcase form
((and `(,op ,fun ,prop ,val)
diff --git a/lisp/subr.el b/lisp/subr.el
index 3e4a3dedf5..42b4e1c211 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2971,12 +2971,7 @@ (defun function-get (f prop &optional autoload)
if it's an autoloaded macro."
(let ((val nil))
(while (and (symbolp f)
- (null (setq val (or (plist-get
- (alist-get
- f (bound-and-true-p
- byte-compile-plist-environment))
- prop)
- (get f prop))))
+ (null (setq val (get f prop)))
(fboundp f))
(let ((fundef (symbol-function f)))
(if (and autoload (autoloadp fundef)
diff --git a/src/fns.c b/src/fns.c
index d849618f2b..655422aa0f 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -1987,6 +1987,14 @@ DEFUN ("get", Fget, Sget, 2, 2, 0,
(Lisp_Object symbol, Lisp_Object propname)
{
CHECK_SYMBOL (symbol);
+ Lisp_Object plist_env = find_symbol_value (Qbyte_compile_plist_environment);
+ if (CONSP (plist_env))
+ {
+ Lisp_Object propval = Fplist_get (CDR (Fassq (symbol, plist_env)),
+ propname);
+ if (!NILP (propval))
+ return propval;
+ }
return Fplist_get (XSYMBOL (symbol)->plist, propname);
}
@@ -5125,6 +5133,8 @@ syms_of_fns (void)
DEFSYM (Qkey_or_value, "key-or-value");
DEFSYM (Qkey_and_value, "key-and-value");
+ DEFSYM (Qbyte_compile_plist_environment, "byte-compile-plist-environment");
+
defsubr (&Ssxhash_eq);
defsubr (&Ssxhash_eql);
defsubr (&Ssxhash_equal);
--
2.11.1
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Mon, 24 Jul 2017 15:31:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 27718 <at> debbugs.gnu.org (full text, mbox):
>> So maybe rather than hijack function-get/put in bug#27016, we should
>> introduce a new "definitional put" with a corresponding `get`, and then
>> use that here as well as in function-put/get.
>> Maybe we could simply change put&get directly without introducing
>> yet-another slightly different get/put?
> Something like this?
I guess so. But:
> + DEFSYM (Qbyte_compile_plist_environment, "byte-compile-plist-environment");
I find having to hardcode byte-compile-plist-environment in get rather ugly.
Stefan "sorry, I couldn't make it more constructive"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Mon, 24 Jul 2017 19:46:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 27718 <at> debbugs.gnu.org (full text, mbox):
>> + DEFSYM (Qbyte_compile_plist_environment, "byte-compile-plist-environment");
> I find having to hardcode byte-compile-plist-environment in get rather ugly.
Hmm... I'm still not quite sure how best to deal with this, but it does
occur to me that we could introduce a new `define-propval' value, which
would be like `put' but for use at top-level. It could differ from
`put' in that the byte-compiler could keep track of those in
byte-compile-plist-environment, and that they could record themselves in
load-history for unload-feature to be able to undo them.
It doesn't help on the `get' side, tho.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Tue, 25 Jul 2017 16:35:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 27718 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 24, 2017 at 3:44 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>>> + DEFSYM (Qbyte_compile_plist_environment, "byte-compile-plist-environment");
>
>> I find having to hardcode byte-compile-plist-environment in get rather ugly.
>
> Hmm... I'm still not quite sure how best to deal with this, but it does
> occur to me that we could introduce a new `define-propval' value, which
> would be like `put' but for use at top-level. It could differ from
> `put' in that the byte-compiler could keep track of those in
> byte-compile-plist-environment, and that they could record themselves in
> load-history for unload-feature to be able to undo them.
>
> It doesn't help on the `get' side, tho.
Right. We need `get' to be aware of what the compiler has read, so it
will need to have a reference to the compiler in there somewhere. We
could name it differently and point the reference in the other
direction, as in DEFSYM (Qalternate_plist_environment...) and have the
byte compiler use that instead, which might be slightly more
aesthetically pleasing. The other possibility is to introduce a
different kind of `get' and use that in places that need to be aware
of what the compiler has read.
I don't see a third option.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Tue, 25 Jul 2017 21:22:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 27718 <at> debbugs.gnu.org (full text, mbox):
> Right. We need `get' to be aware of what the compiler has read, so it
> will need to have a reference to the compiler in there somewhere. We
> could name it differently and point the reference in the other
> direction, as in DEFSYM (Qalternate_plist_environment...) and have the
> byte compiler use that instead, which might be slightly more
> aesthetically pleasing. The other possibility is to introduce a
> different kind of `get' and use that in places that need to be aware
> of what the compiler has read.
> I don't see a third option.
Right, so we have 3 options, indeed:
- `get` looks up to byte-compile-plist-environment
- byte-compile manipulates `get`s overriding-plist-environment
- provide a new get-like function.
Either one is fine by me,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Sat, 05 Aug 2017 01:06:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 27718 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
> Right, so we have 3 options, indeed:
> - `get` looks up to byte-compile-plist-environment
> - byte-compile manipulates `get`s overriding-plist-environment
> - provide a new get-like function.
>
> Either one is fine by me,
I'm thinking the 2nd looks best. Is it correct to `put'
`byte-compile-define-symbol-prop' as the hunk handler for both
`define-symbol-prop' and `function-put'?
[v2-0001-Let-define-symbol-prop-take-effect-during-compila.patch (text/x-diff, inline)]
From 3e8759320ecba4156cd3315ef02ea902ff408ae3 Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Date: Fri, 14 Jul 2017 00:32:34 -0400
Subject: [PATCH v2 1/2] Let `define-symbol-prop' take effect during
compilation
* src/fns.c (syms_of_fns): New variable `overriding-plist-environment'.
(Fget): Consult it.
* lisp/emacs-lisp/bytecomp.el (byte-compile-close-variables): Let-bind
it to nil.
(byte-compile-define-symbol-prop): New function, handles compilation
of top-level `define-symbol-prop' and `function-put' calls by putting
the symbol setting into `overriding-plist-environment'.
Co-authored-by: Noam Postavsky <npostavs <at> gmail.com>
---
lisp/emacs-lisp/bytecomp.el | 29 +++++++++++++++++++++++++++++
src/fns.c | 11 +++++++++++
test/lisp/emacs-lisp/bytecomp-tests.el | 17 +++++++++++++++++
3 files changed, 57 insertions(+)
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index fdd4276e4e..a1626c0b9d 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1572,6 +1572,7 @@ (defmacro byte-compile-close-variables (&rest body)
;; macroenvironment.
(copy-alist byte-compile-initial-macro-environment))
(byte-compile--outbuffer nil)
+ (overriding-plist-environment nil)
(byte-compile-function-environment nil)
(byte-compile-bound-variables nil)
(byte-compile-lexical-variables nil)
@@ -4712,6 +4713,34 @@ (put 'make-variable-buffer-local
'byte-hunk-handler 'byte-compile-form-make-variable-buffer-local)
(defun byte-compile-form-make-variable-buffer-local (form)
(byte-compile-keep-pending form 'byte-compile-normal-call))
+
+(put 'function-put 'byte-hunk-handler 'byte-compile-define-symbol-prop)
+(put 'define-symbol-prop 'byte-hunk-handler 'byte-compile-define-symbol-prop)
+(defun byte-compile-define-symbol-prop (form)
+ (pcase form
+ ((and `(,op ,fun ,prop ,val)
+ (guard (and (macroexp-const-p fun)
+ (macroexp-const-p prop)
+ (or (macroexp-const-p val)
+ ;; Also accept anonymous functions, since
+ ;; we're at top-level which implies they're
+ ;; also constants.
+ (pcase val (`(function (lambda . ,_)) t))))))
+ (byte-compile-push-constant op)
+ (byte-compile-form fun)
+ (byte-compile-form prop)
+ (let* ((fun (eval fun))
+ (prop (eval prop))
+ (val (if (macroexp-const-p val)
+ (eval val)
+ (byte-compile-lambda (cadr val)))))
+ (push `(,fun
+ . (,prop ,val ,@(alist-get fun overriding-plist-environment)))
+ overriding-plist-environment)
+ (byte-compile-push-constant val)
+ (byte-compile-out 'byte-call 3)))
+
+ (_ (byte-compile-keep-pending form))))
;;; tags
diff --git a/src/fns.c b/src/fns.c
index d849618f2b..00b6ed6a28 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -1987,6 +1987,10 @@ DEFUN ("get", Fget, Sget, 2, 2, 0,
(Lisp_Object symbol, Lisp_Object propname)
{
CHECK_SYMBOL (symbol);
+ Lisp_Object propval = Fplist_get (CDR (Fassq (symbol, Voverriding_plist_environment)),
+ propname);
+ if (!NILP (propval))
+ return propval;
return Fplist_get (XSYMBOL (symbol)->plist, propname);
}
@@ -5163,6 +5167,13 @@ syms_of_fns (void)
DEFSYM (Qcursor_in_echo_area, "cursor-in-echo-area");
DEFSYM (Qwidget_type, "widget-type");
+ DEFVAR_LISP ("overriding-plist-environment", Voverriding_plist_environment,
+ doc: /* An alist overrides the plists of the symbols which it lists.
+Used by the byte-compiler to apply `define-symbol-prop' during
+compilation. */);
+ Voverriding_plist_environment = Qnil;
+ DEFSYM (Qoverriding_plist_environment, "overriding-plist-environment");
+
staticpro (&string_char_byte_cache_string);
string_char_byte_cache_string = Qnil;
diff --git a/test/lisp/emacs-lisp/bytecomp-tests.el b/test/lisp/emacs-lisp/bytecomp-tests.el
index d15bd8b6e6..8ef2ce7025 100644
--- a/test/lisp/emacs-lisp/bytecomp-tests.el
+++ b/test/lisp/emacs-lisp/bytecomp-tests.el
@@ -545,6 +545,23 @@ (ert-deftest bytecomp-tests--old-style-backquotes ()
This functionality has been obsolete for more than 10 years already
and will be removed soon. See (elisp)Backquote in the manual.")))))))
+
+(ert-deftest bytecomp-tests-function-put ()
+ "Check `function-put' operates during compilation."
+ (should (boundp 'lread--old-style-backquotes))
+ (bytecomp-tests--with-temp-file source
+ (dolist (form '((function-put 'bytecomp-tests--foo 'foo 1)
+ (function-put 'bytecomp-tests--foo 'bar 2)
+ (defmacro bytecomp-tests--foobar ()
+ `(cons ,(function-get 'bytecomp-tests--foo 'foo)
+ ,(function-get 'bytecomp-tests--foo 'bar)))
+ (defvar bytecomp-tests--foobar 1)
+ (setq bytecomp-tests--foobar (bytecomp-tests--foobar))))
+ (print form (current-buffer)))
+ (write-region (point-min) (point-max) source nil 'silent)
+ (byte-compile-file source t)
+ (should (equal bytecomp-tests--foobar (cons 1 2)))))
+
;; Local Variables:
;; no-byte-compile: t
;; End:
--
2.11.1
[v2-0002-Let-the-cl-typep-effects-of-defclass-work-during-.patch (text/x-diff, inline)]
From 848a5eb1ed15bb975fe308464b2891b160c5a420 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Fri, 4 Aug 2017 19:50:21 -0400
Subject: [PATCH v2 2/2] Let the cl-typep effects of defclass work during
compilation (Bug#27718)
* lisp/emacs-lisp/eieio.el (defclass): Use `define-symbol-prop'
instead of `put'.
---
lisp/emacs-lisp/eieio.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
index 1a7de55fce..8b92d5b7ac 100644
--- a/lisp/emacs-lisp/eieio.el
+++ b/lisp/emacs-lisp/eieio.el
@@ -246,7 +246,7 @@ (defmacro defclass (name superclasses slots &rest options-and-doc)
;; test, so we can let typep have the CLOS documented behavior
;; while keeping our above predicate clean.
- (put ',name 'cl-deftype-satisfies #',testsym2)
+ (define-symbol-prop ',name 'cl-deftype-satisfies #',testsym2)
(eieio-defclass-internal ',name ',superclasses ',slots ',options-and-doc)
--
2.11.1
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Sat, 05 Aug 2017 12:50:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 27718 <at> debbugs.gnu.org (full text, mbox):
>> Right, so we have 3 options, indeed:
>> - `get` looks up to byte-compile-plist-environment
>> - byte-compile manipulates `get`s overriding-plist-environment
>> - provide a new get-like function.
>> Either one is fine by me,
> I'm thinking the 2nd looks best. Is it correct to `put'
> `byte-compile-define-symbol-prop' as the hunk handler for both
> `define-symbol-prop' and `function-put'?
I think so, yes.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27718
; Package
emacs
.
(Tue, 08 Aug 2017 01:15:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 27718 <at> debbugs.gnu.org (full text, mbox):
tags 27718 fixed
close 27718 26.1
quit
Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:
>>> Right, so we have 3 options, indeed:
>>> - `get` looks up to byte-compile-plist-environment
>>> - byte-compile manipulates `get`s overriding-plist-environment
>>> - provide a new get-like function.
>>> Either one is fine by me,
>> I'm thinking the 2nd looks best. Is it correct to `put'
>> `byte-compile-define-symbol-prop' as the hunk handler for both
>> `define-symbol-prop' and `function-put'?
>
> I think so, yes.
Pushed to master.
[1: cc30d77ecd]: 2017-08-07 18:54:49 -0400
Let `define-symbol-prop' take effect during compilation
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=cc30d77ecdd1b9155ade3d0656a84a0839ee2795
[2: b5c8e9898d]: 2017-08-07 18:54:49 -0400
Let the cl-typep effects of defclass work during compilation (Bug#27718)
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b5c8e9898d9dbd4145c40d08e8eef84a5e32008a
Added tag(s) fixed.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Tue, 08 Aug 2017 01:15:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 26.1, send any further explanations to
27718 <at> debbugs.gnu.org and npostavs <at> users.sourceforge.net
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Tue, 08 Aug 2017 01:15:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 05 Sep 2017 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 342 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.