* byte-compiler does *not* complain about missing case or loop
@ 2014-03-05 15:40 Jambunathan K
2014-03-07 20:03 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Jambunathan K @ 2014-03-05 15:40 UTC (permalink / raw)
To: emacs-devel
1. emacs -Q
2. C-x C-f hx.el (hx.el relies on cl but doesn't require it)
3. See the error log below.
Why is the byte-compiler silent about the "missing" `case' and `loop'?
----------------------------------------------------------------
If this should be filed as a report, I will oblige.
Compiling file /home/kjambunathan/.emacs.d/lisp/hx.el at Wed Mar 5 10:32:47 2014
In hx-export:
hx.el:85:36:Warning: `t' called as a function
hx.el:197:9:Warning: reference to free variable `for'
hx.el:197:13:Warning: reference to free variable `markers'
hx.el:197:21:Warning: reference to free variable `in'
hx.el:198:13:Warning: reference to free variable `org-element-type'
hx.el:199:13:Warning: reference to free variable `hx-element-type'
hx.el:200:9:Warning: reference to free variable `collect'
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-05 15:40 byte-compiler does *not* complain about missing case or loop Jambunathan K
@ 2014-03-07 20:03 ` Stefan Monnier
2014-03-08 3:29 ` Jambunathan K
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-07 20:03 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-devel
> Why is the byte-compiler silent about the "missing" `case' and `loop'?
AFAIK it does report them as missing, at the end of the compilation
(it can't report them right away because `loop' and `case' might be
defined as functions further down in the file).
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-07 20:03 ` Stefan Monnier
@ 2014-03-08 3:29 ` Jambunathan K
2014-03-08 7:53 ` Andreas Schwab
2014-03-09 12:26 ` Stefan Monnier
0 siblings, 2 replies; 12+ messages in thread
From: Jambunathan K @ 2014-03-08 3:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 562 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Why is the byte-compiler silent about the "missing" `case' and `loop'?
>
> AFAIK it does report them as missing, at the end of the compilation
> (it can't report them right away because `loop' and `case' might be
> defined as functions further down in the file).
Try the attached test.el (with emacs -Q).
1. The compiler doesn't get to "the end of data" ritual.
2. How would I interpret the error?
1:40 ends points to param line but the actual error report - the
`marker' variable - is elsewhere.
[-- Attachment #2: test.el --]
[-- Type: application/emacs-lisp, Size: 460 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-08 3:29 ` Jambunathan K
@ 2014-03-08 7:53 ` Andreas Schwab
2014-03-08 12:39 ` Jambunathan K
2014-03-09 12:26 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Andreas Schwab @ 2014-03-08 7:53 UTC (permalink / raw)
To: Jambunathan K; +Cc: Stefan Monnier, emacs-devel
Jambunathan K <kjambunathan@gmail.com> writes:
> 2. How would I interpret the error?
>
> 1:40 ends points to param line but the actual error report - the
> `marker' variable - is elsewhere.
(types . marker) is a malformed function call.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-08 7:53 ` Andreas Schwab
@ 2014-03-08 12:39 ` Jambunathan K
2014-03-09 12:45 ` Andreas Schwab
0 siblings, 1 reply; 12+ messages in thread
From: Jambunathan K @ 2014-03-08 12:39 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Andreas Schwab <schwab@linux-m68k.org> writes:
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> 2. How would I interpret the error?
>>
>> 1:40 ends points to param line but the actual error report - the
>> `marker' variable - is elsewhere.
>
> (types . marker) is a malformed function call.
The LINE:COL position of the error report is wrong.
The presence of that defun prevents the "end of data" report from being
triggered.
FWIW, see the attached report
1. With the offending defun compiled in, the "end of data" report is
*absent*.
2. With offending defun ";;"-ed out, the "end of data" report is
*present*.
I wonder what would explain the presence/absence of "end of data"
report.
[-- Attachment #2: with-destructuring.txt --]
[-- Type: text/plain, Size: 801 bytes --]
\f
Compiling file /home/kjambunathan/.emacs.d/lisp/hx.el at Sat Mar 8 17:50:52 2014
In hx-export:
hx.el:85:36:Warning: `t' called as a function
hx.el:210:9:Warning: reference to free variable `for'
hx.el:210:13:Warning: reference to free variable `markers'
hx.el:210:21:Warning: reference to free variable `in'
hx.el:211:13:Warning: reference to free variable `org-element-type'
hx.el:212:13:Warning: reference to free variable `hx-element-type'
hx.el:213:9:Warning: reference to free variable `collect'
In hx-org-li:
hx.el:300:42:Warning: reference to free variable `for'
hx.el:300:46:Warning: reference to free variable `html'
hx.el:300:51:Warning: reference to free variable `in'
hx.el:300:70:Warning: reference to free variable `count'
hx.el:418:40:Error: Wrong type argument: sequencep, marker
[-- Attachment #3: without-destructuring.txt --]
[-- Type: text/plain, Size: 1963 bytes --]
\f
Compiling file /home/kjambunathan/.emacs.d/lisp/hx.el at Sat Mar 8 17:52:15 2014
In hx-export:
hx.el:85:36:Warning: `t' called as a function
hx.el:210:9:Warning: reference to free variable `for'
hx.el:210:13:Warning: reference to free variable `markers'
hx.el:210:21:Warning: reference to free variable `in'
hx.el:211:13:Warning: reference to free variable `org-element-type'
hx.el:212:13:Warning: reference to free variable `hx-element-type'
hx.el:213:9:Warning: reference to free variable `collect'
In hx-org-li:
hx.el:300:42:Warning: reference to free variable `for'
hx.el:300:46:Warning: reference to free variable `html'
hx.el:300:51:Warning: reference to free variable `in'
hx.el:300:70:Warning: reference to free variable `count'
In hx-export-to-file:
hx.el:477:39:Warning: reference to free variable `hx-backends-alist'
hx.el:523:13:Warning: `:constructor' called as a function
hx.el:523:38:Warning: reference to free variable `hx-create-backend'
hx.el:523:38:Warning: `:copier' called as a function
hx.el:525:3:Warning: reference to free variable `name'
hx.el:525:8:Warning: reference to free variable `parent'
hx.el:525:15:Warning: reference to free variable `transcoders'
hx.el:525:27:Warning: reference to free variable `content-selector'
hx.el:525:44:Warning: reference to free variable `post-processor'
In hx-tex-post-processor:
hx.el:683:25:Warning: reference to free variable `for'
hx.el:683:29:Warning: reference to free variable `field'
hx.el:683:35:Warning: reference to free variable `in'
hx.el:684:25:Warning: reference to free variable `always'
In end of data:
hx.el:773:1:Warning: the following functions are not known to be defined: case, t,
hx-backend-transcoders, cdddr, caddr, remove-if,
pp-display-expression, loop, hx-org-text-markup, h1, h2, h3, h4,
h5, h6, ol, ul, otherwise, hx-backend-content-selector,
hx-backend-post-processor, defstruct, hx-backend, :constructor,
:copier, hx-create-backend, assert
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-08 3:29 ` Jambunathan K
2014-03-08 7:53 ` Andreas Schwab
@ 2014-03-09 12:26 ` Stefan Monnier
2014-03-09 14:38 ` Jambunathan K
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-09 12:26 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-devel
> 1. The compiler doesn't get to "the end of data" ritual.
No, because it hits an actual error and just stops there, without even
generating a .elc file.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-08 12:39 ` Jambunathan K
@ 2014-03-09 12:45 ` Andreas Schwab
0 siblings, 0 replies; 12+ messages in thread
From: Andreas Schwab @ 2014-03-09 12:45 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-devel
Jambunathan K <kjambunathan@gmail.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Jambunathan K <kjambunathan@gmail.com> writes:
>>
>>> 2. How would I interpret the error?
>>>
>>> 1:40 ends points to param line but the actual error report - the
>>> `marker' variable - is elsewhere.
>>
>> (types . marker) is a malformed function call.
>
> The LINE:COL position of the error report is wrong.
I wouldn't have noticed if you didn't call my attention.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-09 12:26 ` Stefan Monnier
@ 2014-03-09 14:38 ` Jambunathan K
2014-03-10 4:33 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Jambunathan K @ 2014-03-09 14:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 1. The compiler doesn't get to "the end of data" ritual.
>
> No, because it hits an actual error and just stops there, without even
> generating a .elc file.
Should it stop just there?
It can pretend as though the faulty defun was not there in first place
and go through the motions (without generating the .elc file). It would
help if the compiler dumps an "end of data" report.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-09 14:38 ` Jambunathan K
@ 2014-03-10 4:33 ` Stefan Monnier
2014-03-10 6:48 ` Jambunathan K
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-10 4:33 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-devel
>>> 1. The compiler doesn't get to "the end of data" ritual.
>> No, because it hits an actual error and just stops there, without even
>> generating a .elc file.
> Should it stop just there?
You mean, should it have better "error recovery"? I'd agree
that it would be better if it could recover in such a case.
But I think I'd only accept a patch for it if it can be implemented in
a simple/clean way, because the benefit is fairly small.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-10 4:33 ` Stefan Monnier
@ 2014-03-10 6:48 ` Jambunathan K
2014-03-10 14:20 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Jambunathan K @ 2014-03-10 6:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> "error recovery"?
Did you notice the *wrong* LINE:COL reporting? Does that fall under
"error recovery" as well.
http://lists.gnu.org/archive/html/emacs-devel/2014-03/msg00269.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-10 6:48 ` Jambunathan K
@ 2014-03-10 14:20 ` Stefan Monnier
2014-03-11 4:12 ` Jambunathan K
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-03-10 14:20 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-devel
>> "error recovery"?
> Did you notice the *wrong* LINE:COL reporting?
Didn't you notice that *all* LINE:COL data is "approximate"
in the byte-compiler's output?
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: byte-compiler does *not* complain about missing case or loop
2014-03-10 14:20 ` Stefan Monnier
@ 2014-03-11 4:12 ` Jambunathan K
0 siblings, 0 replies; 12+ messages in thread
From: Jambunathan K @ 2014-03-11 4:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> "error recovery"?
>> Did you notice the *wrong* LINE:COL reporting?
>
> Didn't you notice that *all* LINE:COL data is "approximate"
> in the byte-compiler's output?
This is an excuse I can allow :-).
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-03-11 4:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-05 15:40 byte-compiler does *not* complain about missing case or loop Jambunathan K
2014-03-07 20:03 ` Stefan Monnier
2014-03-08 3:29 ` Jambunathan K
2014-03-08 7:53 ` Andreas Schwab
2014-03-08 12:39 ` Jambunathan K
2014-03-09 12:45 ` Andreas Schwab
2014-03-09 12:26 ` Stefan Monnier
2014-03-09 14:38 ` Jambunathan K
2014-03-10 4:33 ` Stefan Monnier
2014-03-10 6:48 ` Jambunathan K
2014-03-10 14:20 ` Stefan Monnier
2014-03-11 4:12 ` Jambunathan K
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).