* 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 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-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-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).