* bug#6740: Spurious byte compiler warnings @ 2010-07-27 20:06 Alan Mackenzie 2010-07-27 20:26 ` Dan Nicolaescu 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2010-07-27 20:06 UTC (permalink / raw To: 6740 Hi, Emacs! (i) Start Emacs, even a most recent bzr version, with -Q. (ii) Put the following into the *scratch* buffer: (eval-when-compile (if (and (not (featurep 'cc-fix)) (featurep 'xemacs) (progn (require 'font-lock) (let (font-lock-keywords) (font-lock-compile-keywords '("\\<\\>")) font-lock-keywords))) (cc-load "cc-fix"))) (This fragment is at the top level, and taken from cc-defs.el.). (iii) do M-x compile-defun on this form. The byte compiler then issues the following two identical error messages: Warning: value returned from (featurep (quote cc-fix)) is unused Warning: value returned from (featurep (quote cc-fix)) is unused It is obvious that that value is indeed used. This is a bug. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 20:06 bug#6740: Spurious byte compiler warnings Alan Mackenzie @ 2010-07-27 20:26 ` Dan Nicolaescu 2010-07-27 21:23 ` Alan Mackenzie 2010-07-27 21:40 ` Stefan Monnier 0 siblings, 2 replies; 14+ messages in thread From: Dan Nicolaescu @ 2010-07-27 20:26 UTC (permalink / raw To: Alan Mackenzie; +Cc: 6740 Alan Mackenzie <acm@muc.de> writes: > Hi, Emacs! > > (i) Start Emacs, even a most recent bzr version, with -Q. > (ii) Put the following into the *scratch* buffer: > > (eval-when-compile > (if (and (not (featurep 'cc-fix)) > (featurep 'xemacs) > (progn > (require 'font-lock) > (let (font-lock-keywords) > (font-lock-compile-keywords '("\\<\\>")) > font-lock-keywords))) > (cc-load "cc-fix"))) > > (This fragment is at the top level, and taken from cc-defs.el.). > (iii) do M-x compile-defun on this form. > > The byte compiler then issues the following two identical error > messages: > > Warning: value returned from (featurep (quote cc-fix)) is unused > Warning: value returned from (featurep (quote cc-fix)) is unused > > It is obvious that that value is indeed used. This is a bug. The byte compiler knows that (featurep 'xemacs) is false, so (and (not (featurep 'cc-fix)) ... ) will be false, so the featurep result is indeed unused. If you use (and (featurep 'xemacs) (not (featurep 'cc-fix) ... the warning will go away. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 20:26 ` Dan Nicolaescu @ 2010-07-27 21:23 ` Alan Mackenzie 2010-07-27 22:57 ` Juanma Barranquero 2010-07-27 21:40 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2010-07-27 21:23 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 6740 Hi, Dan, On Tue, Jul 27, 2010 at 04:26:03PM -0400, Dan Nicolaescu wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hi, Emacs! > > (i) Start Emacs, even a most recent bzr version, with -Q. > > (ii) Put the following into the *scratch* buffer: > > (eval-when-compile > > (if (and (not (featurep 'cc-fix)) > > (featurep 'xemacs) > > (progn > > (require 'font-lock) > > (let (font-lock-keywords) > > (font-lock-compile-keywords '("\\<\\>")) > > font-lock-keywords))) > > (cc-load "cc-fix"))) > > (This fragment is at the top level, and taken from cc-defs.el.). > > (iii) do M-x compile-defun on this form. > > The byte compiler then issues the following two identical error > > messages: > > Warning: value returned from (featurep (quote cc-fix)) is unused > > Warning: value returned from (featurep (quote cc-fix)) is unused > > It is obvious that that value is indeed used. This is a bug. > The byte compiler knows that (featurep 'xemacs) is false, so > (and (not (featurep 'cc-fix)) ... ) > will be false, so the featurep result is indeed unused. Ah, thanks for the explanation! But ..... It's a bug that the error message is repeated, at the very least. And the message is most assuredly false because (featurep 'cc-fix) isn't always false - for example when it's run under XEmacs. > If you use (and (featurep 'xemacs) (not (featurep 'cc-fix) ... > the warning will go away. At the very least, emitting such arcane warnings is unhelpful. Are there any circumstances in which such a warning might help a hacker improve his code? Surely we aren't in the business of making it difficult to adapt code for XEmacs? I think it's clear, the only code containing (featurep 'xemacs) is portable code. Can we please remove this unhelpful warning? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 21:23 ` Alan Mackenzie @ 2010-07-27 22:57 ` Juanma Barranquero 2010-07-28 17:49 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Juanma Barranquero @ 2010-07-27 22:57 UTC (permalink / raw To: Alan Mackenzie; +Cc: Dan Nicolaescu, 6740 On Tue, Jul 27, 2010 at 23:23, Alan Mackenzie <acm@muc.de> wrote: > It's a bug that the error message is repeated, at the very least. Yes, likely. > And > the message is most assuredly false because (featurep 'cc-fix) isn't > always false - for example when it's run under XEmacs. Not, in code byte-compiled for Emacs it is always false because (featurep 'xemacs) is false. That means that optimized bytecode is not portable to XEmacs. But I don't think it was before (for a long time). > At the very least, emitting such arcane warnings is unhelpful. Are there > any circumstances in which such a warning might help a hacker improve his > code? Surely we aren't in the business of making it difficult to adapt > code for XEmacs? You make it appear as it if were an attempt to warn about using XEmacs-specific code, but it is not, as Dan has pointed out. The warning is generic, the result of (and X (featurep 'xemacs) Y Z...) => (prog (and X) nil) => (prog X nil) ; IIUC the comments in byte-opt.el... from whence, "value returned from X is unused". > I think it's clear, the only code containing (featurep 'xemacs) is > portable code. The code is portable. The .elc is not. Juanma ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 22:57 ` Juanma Barranquero @ 2010-07-28 17:49 ` Alan Mackenzie 2010-07-28 17:56 ` Juanma Barranquero 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2010-07-28 17:49 UTC (permalink / raw To: Juanma Barranquero; +Cc: Dan Nicolaescu, 6740 Hi, Juanma, On Wed, Jul 28, 2010 at 12:57:04AM +0200, Juanma Barranquero wrote: > On Tue, Jul 27, 2010 at 23:23, Alan Mackenzie <acm@muc.de> wrote: > > It's a bug that the error message is repeated, at the very least. > Yes, likely. > > And the message is most assuredly false because (featurep 'cc-fix) > > isn't always false - for example when it's run under XEmacs. > Not, in code byte-compiled for Emacs it is always false because > (featurep 'xemacs) is false. That means that optimized bytecode is not > portable to XEmacs. But I don't think it was before (for a long time). Optimised .elc isn't even compatible with earlier versions of Emacs. But this discussion is most emphatically NOT about compiled code. It's about the process of compiling sources. > > At the very least, emitting such arcane warnings is unhelpful. Are > > there any circumstances in which such a warning might help a hacker > > improve his code? Surely we aren't in the business of making it > > difficult to adapt code for XEmacs? > You make it appear as it if were an attempt to warn about using > XEmacs-specific code, but it is not, as Dan has pointed out. What use is this warning message? How could it prompt a hacker to improve his code? (That's a genuine question, not a rhetorical one.) > The warning is generic, the result of > (and X (featurep 'xemacs) Y Z...) => (prog (and X) nil) => (prog X > nil) ; IIUC the comments in byte-opt.el... Thanks for this explanation. What do you mean by "generic" here? Is the same trick performed on symbols other than 'xemacs? Surely it is a bug that "(featurep 'cc-fix)" appears in the message rather than "(featurep 'xemacs)". This situation is not about 'cc-fix, it's about 'xemacs. I would suggest that if I, a highly experienced Emacs hacker, remain baffled by this message over many months, so will lots of others. Does anybody actually care about "(featurep 'xemacs)" being optimised away? Again, who does this warning message help (other than the hackers who wrote the optimisation code in the first place, of course)? > from whence, "value returned from X is unused". > > I think it's clear, the only code containing (featurep 'xemacs) is > > portable code. > The code is portable. The .elc is not. Er, we're in strong agreement with this. > Juanma -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-28 17:49 ` Alan Mackenzie @ 2010-07-28 17:56 ` Juanma Barranquero 2010-07-28 19:45 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Juanma Barranquero @ 2010-07-28 17:56 UTC (permalink / raw To: Alan Mackenzie; +Cc: Dan Nicolaescu, 6740 > But > this discussion is most emphatically NOT about compiled code. It's about > the process of compiling sources. Warnings do not affect compatibility, so no problem there (though I admit they are ugly). > What use is this warning message? How could it prompt a hacker to > improve his code? (That's a genuine question, not a rhetorical one.) It's a warning about non-side-effects code whose result is discarded, so it obviously prompts the programmer to either check that it didn't make a mistake (like forgetting to assign the expression's result to a variable), or remove the code altogether if it is leftover code from a cut&paste or refactoring. > What do you mean by "generic" here? Is the same trick performed on > symbols other than 'xemacs? The warning has *nothing* to do with the xemacs symbol. It would still be there if you did "(and (not (featurep 'cc-fix)) nil ...)". It just happens to be triggered, in this particular case, by the byte-compiler optimizing (featurep 'xemacs) to nil. So the warning is entirely generic. > Surely it is a bug that "(featurep 'cc-fix)" appears in the message > rather than "(featurep 'xemacs)". This situation is not about 'cc-fix, > it's about 'xemacs. Absolutely no, as shown above. At the point the byte-compiler throws the warning, it does not know (I think) where the relevant nil came from. It is rightly complaining that (featurep 'cc-fix) does nothing and returns a value that goes unused. It would be possible to store the original code before optimization and pass it to the warning generation code, but it is likely not worth it. > Does > anybody actually care about "(featurep 'xemacs)" being optimised away? IIRC, optimizing (featurep 'xemacs) => nil is done, *precisely*, to help compiling portable code. Because you can have (if (featurep 'xemacs) ;; lots of code which would throw warnings or errors on Emacs ;; because of incompatible parameter profiles and such ;; else ;; code for emacs and compile it without getting warnings of errors in code that will never be executed on Emacs anyway. Juanma ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-28 17:56 ` Juanma Barranquero @ 2010-07-28 19:45 ` Alan Mackenzie 2010-07-28 19:54 ` Juanma Barranquero 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2010-07-28 19:45 UTC (permalink / raw To: Juanma Barranquero; +Cc: Dan Nicolaescu, 6740 Hi, Juanma, On Wed, Jul 28, 2010 at 07:56:32PM +0200, Juanma Barranquero wrote: > > What use is this warning message? How could it prompt a hacker to > > improve his code? (That's a genuine question, not a rhetorical one.) > It's a warning about non-side-effects code whose result is discarded, > so it obviously prompts the programmer to either check that it didn't > make a mistake (like forgetting to assign the expression's result to a > variable), or remove the code altogether if it is leftover code from a > cut&paste or refactoring. OK, thanks. > > What do you mean by "generic" here? Is the same trick performed on > > symbols other than 'xemacs? > The warning has *nothing* to do with the xemacs symbol. It would still > be there if you did "(and (not (featurep 'cc-fix)) nil ...)". It just > happens to be triggered, in this particular case, by the byte-compiler > optimizing (featurep 'xemacs) to nil. So the warning is entirely > generic. I'm not any more doubting the correctness of the message; I'm doubting its adequacy. Without understanding that (featurep 'xemacs) has been optimised to nil, it's impossible to understand the current message (either of them). I've spent a long, long time puzzling over this error message. If only there were a warning about 'xemacs, it would be plain and obvious. > > Does anybody actually care about "(featurep 'xemacs)" being optimised > > away? > IIRC, optimizing (featurep 'xemacs) => nil is done, *precisely*, to > help compiling portable code. Misunderstanding, sorry! I'm all in favour of this optimisation being done. But I don't care about it, in the sense I don't want to have to make sense of a confusing message about it. Does anybody care about it enough to want that message in this particular case? Couldn't the optimisation just be done quietly in the background, with no warning? Or couldn't there be a warning like "`(featurep 'xemacs)' has been translated to nil" ? > Because you can have > (if (featurep 'xemacs) > ;; lots of code which would throw warnings or errors on Emacs > ;; because of incompatible parameter profiles and such > ;; else > ;; code for emacs > and compile it without getting warnings of errors in code that will > never be executed on Emacs anyway. OK, I can see that. > Juanma -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-28 19:45 ` Alan Mackenzie @ 2010-07-28 19:54 ` Juanma Barranquero 2010-07-28 23:00 ` Dan Nicolaescu 2010-07-29 20:24 ` Alan Mackenzie 0 siblings, 2 replies; 14+ messages in thread From: Juanma Barranquero @ 2010-07-28 19:54 UTC (permalink / raw To: Alan Mackenzie; +Cc: Dan Nicolaescu, 6740 On Wed, Jul 28, 2010 at 21:45, Alan Mackenzie <acm@muc.de> wrote: > I'm doubting > its adequacy. Without understanding that (featurep 'xemacs) has been > optimised to nil, it's impossible to understand the current message I think the message is a good hint that something is being statically determined to be nil inside an `and'. > (either of them). Yes, that's a bug :-) > If only there were a warning about 'xemacs, it would be plain > and obvious. But, as I've explained, there cannot (easily) be a waning about `xemacs'; it would have to be about any code that statically evaluates to nil in such a context. I'm not sure how clean that would be to implement, and anyway no one has been bothered enough to try it. > Does anybody care about > it enough to want that message in this particular case? Yes. You don't know whether a warning is relevant or not unless you get it. In *this* particular case, all you need to quiet the byte-compiler is @@ -1,5 +1,5 @@ (eval-when-compile - (if (and (not (featurep 'cc-fix)) - (featurep 'xemacs) + (if (and (featurep 'xemacs) + (not (featurep 'cc-fix)) (progn (require 'font-lock) > Couldn't the > optimisation just be done quietly in the background, with no warning? Why? The optimization is detecting something suspicious, and acting accordingly. > Or couldn't there be a warning like > > "`(featurep 'xemacs)' has been translated to nil" ???? That's worse that what you're complaining now; every use of (featurep 'xemacs) in the sources would produce warnings! Juanma ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-28 19:54 ` Juanma Barranquero @ 2010-07-28 23:00 ` Dan Nicolaescu 2010-07-29 20:24 ` Alan Mackenzie 1 sibling, 0 replies; 14+ messages in thread From: Dan Nicolaescu @ 2010-07-28 23:00 UTC (permalink / raw To: Juanma Barranquero; +Cc: 6740 Juanma Barranquero <lekktu@gmail.com> writes: > On Wed, Jul 28, 2010 at 21:45, Alan Mackenzie <acm@muc.de> wrote: > >> >> "`(featurep 'xemacs)' has been translated to nil" > > ???? > > That's worse that what you're complaining now; every use of (featurep > 'xemacs) in the sources would produce warnings! Exactly, and it would defeat the purpose of optimizing away (featurp 'xemacs) (and (featurep 'emacs): being able to have a single source base that works on both platforms, and it can be compiled warning free. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-28 19:54 ` Juanma Barranquero 2010-07-28 23:00 ` Dan Nicolaescu @ 2010-07-29 20:24 ` Alan Mackenzie 2010-07-29 20:36 ` Juanma Barranquero 1 sibling, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2010-07-29 20:24 UTC (permalink / raw To: Juanma Barranquero; +Cc: Dan Nicolaescu, 6740 Hi, Juanma, On Wed, Jul 28, 2010 at 09:54:04PM +0200, Juanma Barranquero wrote: > On Wed, Jul 28, 2010 at 21:45, Alan Mackenzie <acm@muc.de> wrote: > > I'm doubting its adequacy. Without understanding that (featurep > > 'xemacs) has been optimised to nil, it's impossible to understand the > > current message > I think the message is a good hint that something is being statically > determined to be nil inside an `and'. No, sorry it isn't. It's a good hint that there's a bug in the byte compiler, the tentative conclusion I came to after trying various things. If it were such a good hint, I wouldn't have spent several hours of bafflement trying to figure out what was wrong. Or is it just me who's uniquely stupid? Is there anybody here listening in who's seen this message and immediately understood it? Abstractly seen, the warning did not relate to my source code; it related to an internal, transformed, different piece of source created by the compiler. I think warning messages should always be wrt the original code. > > If only there were a warning about 'xemacs, it would be plain and > > obvious. > But, as I've explained, there cannot (easily) be a warning about > `xemacs'; it would have to be about any code that statically evaluates > to nil in such a context. No. It would be about code which the _compiler_ had transformed to a static nil. The cause of my confusion was that silent change to 'xemacs. There are surely not too many situations where the compiler does this, are there? > I'm not sure how clean that would be to implement, and anyway no one > has been bothered enough to try it. :-) I know nothing of the byte compiler, but maybe I'll give it a go sometime. > > Does anybody care about it enough to want that message in this > > particular case? > Yes. You don't know whether a warning is relevant or not unless you > get it. In *this* particular case, all you need to quiet the > byte-compiler is > @@ -1,5 +1,5 @@ > (eval-when-compile > - (if (and (not (featurep 'cc-fix)) > - (featurep 'xemacs) > + (if (and (featurep 'xemacs) > + (not (featurep 'cc-fix)) > (progn > (require 'font-lock) Yes; I've already made that change, thanks! But what is the process by which I'm meant to come to sufficient understanding to be able figure this out? > > Couldn't the optimisation just be done quietly in the background, > > with no warning? > Why? The optimization is detecting something suspicious, and acting > accordingly. There's nothing suspicious about having (featurep 'xemacs) in the middle of an `and' form. I agree there would be something suspicious about having a bare `nil' there. Can't the compiler figure out the difference between these two cases somehow? > > Or couldn't there be a warning like > > "`(featurep 'xemacs)' has been translated to nil" > ???? > That's worse that what you're complaining now; every use of (featurep > 'xemacs) in the sources would produce warnings! Oh, all right then. Can I ask you to come up with some form of warning which, several years ago, would have saved me all these hours of frustration? > Juanma -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-29 20:24 ` Alan Mackenzie @ 2010-07-29 20:36 ` Juanma Barranquero 0 siblings, 0 replies; 14+ messages in thread From: Juanma Barranquero @ 2010-07-29 20:36 UTC (permalink / raw To: Alan Mackenzie; +Cc: Dan Nicolaescu, 6740 On Thu, Jul 29, 2010 at 22:24, Alan Mackenzie <acm@muc.de> wrote: > No, sorry it isn't. It's a good hint that there's a bug in the byte > compiler, the tentative conclusion I came to after trying various things. No, of course not, because there's no bug (well, other than the duplicate message). The warning is obscure, yes. Warnings about optimized code often are. I agree that it'd be good to have better warnings and error messages (something like "optimization X has rendered code Y unused", perhaps). IIRC, there's published research about good error messages in the face of program transformations. > If it were such a good hint, I wouldn't have spent several hours of > bafflement trying to figure out what was wrong. Or is it just me who's > uniquely stupid? It's not about being stupid, only about knowing a bit what the bytecompiler does, or not. You didn't, and you're *right* that the warning is difficult to interpret. > Is there anybody here listening in who's seen this > message and immediately understood it? Well, I did, but I remembered the (featurep 'xemacs) optimization so I had a head start. > Abstractly seen, the warning did not relate to my source code; it related > to an internal, transformed, different piece of source created by the > compiler. I think warning messages should always be wrt the original > code. Agreed. > The cause of my confusion was that silent change to 'xemacs. > There are surely not too many situations where the compiler does this, > are there? Even if there aren't many, optimizations could be added later; for example, to statically determine that (= 0 0) is t, or even that (and (> x 0) (< x 0)) is nil. > Yes; I've already made that change, thanks! But what is the process by > which I'm meant to come to sufficient understanding to be able figure > this out? That's a good question. > There's nothing suspicious about having (featurep 'xemacs) in the middle > of an `and' form. No, but the warning isn't about that. Is about unused side-effect-free code. > I agree there would be something suspicious about > having a bare `nil' there. Can't the compiler figure out the difference > between these two cases somehow? Yes, it could. Again, no one has bothered to implement it, because these kinds of problems aren't common (most warnings are relatively understandable withouth delving into the bytecompiler sources). > Oh, all right then. Can I ask you to come up with some form of warning > which, several years ago, would have saved me all these hours of > frustration? Not me. I understand what the bytecompiler is doing (at least, I think I do) but I'll leave fixing it for the experts. Juanma ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 20:26 ` Dan Nicolaescu 2010-07-27 21:23 ` Alan Mackenzie @ 2010-07-27 21:40 ` Stefan Monnier 2020-11-19 4:25 ` Stefan Kangas 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2010-07-27 21:40 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 6740 >> Warning: value returned from (featurep (quote cc-fix)) is unused >> Warning: value returned from (featurep (quote cc-fix)) is unused >> >> It is obvious that that value is indeed used. This is a bug. > The byte compiler knows that (featurep 'xemacs) is false, so > (and (not (featurep 'cc-fix)) ... ) > will be false, so the featurep result is indeed unused. > If you use (and (featurep 'xemacs) (not (featurep 'cc-fix) ... > the warning will go away. It's one of those cases where the warning is the result of a check done "too late" (i.e. after some optimization), which means the check is not performed on the code the user sees, but on some massaged version of it. It's difficult to avoid them, short of removing all "code improvement" warnings. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2010-07-27 21:40 ` Stefan Monnier @ 2020-11-19 4:25 ` Stefan Kangas 2020-11-24 6:40 ` Lars Ingebrigtsen 0 siblings, 1 reply; 14+ messages in thread From: Stefan Kangas @ 2020-11-19 4:25 UTC (permalink / raw To: Stefan Monnier; +Cc: Dan Nicolaescu, Alan Mackenzie, 6740 Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Warning: value returned from (featurep (quote cc-fix)) is unused >>> Warning: value returned from (featurep (quote cc-fix)) is unused >>> >>> It is obvious that that value is indeed used. This is a bug. > >> The byte compiler knows that (featurep 'xemacs) is false, so >> (and (not (featurep 'cc-fix)) ... ) >> will be false, so the featurep result is indeed unused. > >> If you use (and (featurep 'xemacs) (not (featurep 'cc-fix) ... >> the warning will go away. > > It's one of those cases where the warning is the result of a check done > "too late" (i.e. after some optimization), which means the check is not > performed on the code the user sees, but on some massaged version of it. > It's difficult to avoid them, short of removing all "code > improvement" warnings. (That was 10 years ago.) I think this is a very minor issue that is likely not worth spending any time on. In any case, it's not even clear what the fix would be or if a different behavior would improve the situation. Does anyone object to closing this as wontfix? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#6740: Spurious byte compiler warnings 2020-11-19 4:25 ` Stefan Kangas @ 2020-11-24 6:40 ` Lars Ingebrigtsen 0 siblings, 0 replies; 14+ messages in thread From: Lars Ingebrigtsen @ 2020-11-24 6:40 UTC (permalink / raw To: Stefan Kangas; +Cc: Dan Nicolaescu, 6740, Stefan Monnier, Alan Mackenzie Stefan Kangas <stefan@marxist.se> writes: > I think this is a very minor issue that is likely not worth spending any > time on. In any case, it's not even clear what the fix would be or if > a different behavior would improve the situation. > > Does anyone object to closing this as wontfix? Well, it is a real bug (and somewhat annoying), so I think it should be left open. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-11-24 6:40 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-27 20:06 bug#6740: Spurious byte compiler warnings Alan Mackenzie 2010-07-27 20:26 ` Dan Nicolaescu 2010-07-27 21:23 ` Alan Mackenzie 2010-07-27 22:57 ` Juanma Barranquero 2010-07-28 17:49 ` Alan Mackenzie 2010-07-28 17:56 ` Juanma Barranquero 2010-07-28 19:45 ` Alan Mackenzie 2010-07-28 19:54 ` Juanma Barranquero 2010-07-28 23:00 ` Dan Nicolaescu 2010-07-29 20:24 ` Alan Mackenzie 2010-07-29 20:36 ` Juanma Barranquero 2010-07-27 21:40 ` Stefan Monnier 2020-11-19 4:25 ` Stefan Kangas 2020-11-24 6:40 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.