all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* byte compiler warnings when bootstrapping
@ 2007-10-21  7:38 Dan Nicolaescu
  2007-10-21  9:50 ` martin rudalics
  2007-10-21 14:05 ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Dan Nicolaescu @ 2007-10-21  7:38 UTC (permalink / raw)
  To: emacs-devel


When bootstrapping the number of byte compiler warnings is huge.

A few bugs could have been caught earlier if the problematic warnings
would have been easier to find.

Wouldn't it be better if an effort would be made to get rid of most
(if not all) the warnings?

To get rid of some of the "function is not known to be defined"
warnings it would be good if we had a way to tell the byte compiler
to not warn about a function not being defined. 

With that and with adding a few more (eval-when-compile (require 'blah))
we should be able to get rid of most warnings. 

Is this a worthy goal? Opinions? 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21  7:38 byte compiler warnings when bootstrapping Dan Nicolaescu
@ 2007-10-21  9:50 ` martin rudalics
  2007-10-22  9:00   ` Richard Stallman
  2007-10-21 14:05 ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: martin rudalics @ 2007-10-21  9:50 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

> When bootstrapping the number of byte compiler warnings is huge.
> 
> A few bugs could have been caught earlier if the problematic warnings
> would have been easier to find.
> 
> Wouldn't it be better if an effort would be made to get rid of most
> (if not all) the warnings?
> 
> To get rid of some of the "function is not known to be defined"
> warnings it would be good if we had a way to tell the byte compiler
> to not warn about a function not being defined. 
> 
> With that and with adding a few more (eval-when-compile (require 'blah))
> we should be able to get rid of most warnings. 
> 
> Is this a worthy goal? Opinions? 

Very worthy, IMHO.

Thanks also for taking care of the next-/previous-line annoyances.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21  7:38 byte compiler warnings when bootstrapping Dan Nicolaescu
  2007-10-21  9:50 ` martin rudalics
@ 2007-10-21 14:05 ` Stefan Monnier
  2007-10-21 15:58   ` Dan Nicolaescu
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2007-10-21 14:05 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

> With that and with adding a few more (eval-when-compile (require 'blah))

What is the use of (eval-when-compile (require 'blah)) in this context?
I expect it's the wrong solution.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 14:05 ` Stefan Monnier
@ 2007-10-21 15:58   ` Dan Nicolaescu
  2007-10-21 16:15     ` David Kastrup
  2007-10-21 19:38     ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 15:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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

  > > With that and with adding a few more (eval-when-compile (require 'blah))
  > 
  > What is the use of (eval-when-compile (require 'blah)) in this context?
  > I expect it's the wrong solution.

When the number of warnings for undefined functions is too high it
might be better to just require the package that defines them. But you
might be right...

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 15:58   ` Dan Nicolaescu
@ 2007-10-21 16:15     ` David Kastrup
  2007-10-21 16:33       ` Dan Nicolaescu
  2007-10-21 19:38     ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: David Kastrup @ 2007-10-21 16:15 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Stefan Monnier, emacs-devel

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>   > > With that and with adding a few more (eval-when-compile (require 'blah))
>   > 
>   > What is the use of (eval-when-compile (require 'blah)) in this context?
>   > I expect it's the wrong solution.
>
> When the number of warnings for undefined functions is too high it
> might be better to just require the package that defines them. But you
> might be right...

But how do the functions actually get defined at runtime?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 16:15     ` David Kastrup
@ 2007-10-21 16:33       ` Dan Nicolaescu
  2007-10-21 18:44         ` David Kastrup
  0 siblings, 1 reply; 19+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 16:33 UTC (permalink / raw)
  To: David Kastrup; +Cc: Stefan Monnier, emacs-devel

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > >
  > >   > > With that and with adding a few more (eval-when-compile (require 'blah))
  > >   > 
  > >   > What is the use of (eval-when-compile (require 'blah)) in this context?
  > >   > I expect it's the wrong solution.
  > >
  > > When the number of warnings for undefined functions is too high it
  > > might be better to just require the package that defines them. But you
  > > might be right...
  > 
  > But how do the functions actually get defined at runtime?

Autoloading

(defun foo ()
  (info)
  (Info-read-node-name) <- this gets a byte compiler a warning,
                           but it is defined at runtime.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 16:33       ` Dan Nicolaescu
@ 2007-10-21 18:44         ` David Kastrup
  0 siblings, 0 replies; 19+ messages in thread
From: David Kastrup @ 2007-10-21 18:44 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Stefan Monnier, emacs-devel

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > Stefan Monnier <monnier@iro.umontreal.ca> writes:
>   > >
>   > >   > > With that and with adding a few more (eval-when-compile
>   > >   > > (require 'blah))
>   > >   > 
>   > >   > What is the use of (eval-when-compile (require 'blah)) in
>   > >   > this context?  I expect it's the wrong solution.
>   > >
>   > > When the number of warnings for undefined functions is too high it
>   > > might be better to just require the package that defines them. But you
>   > > might be right...
>   > 
>   > But how do the functions actually get defined at runtime?
>
> Autoloading
>
> (defun foo ()
>   (info)
>   (Info-read-node-name) <- this gets a byte compiler a warning,

That is not a good idea since it relies on info and
Info-read-node-name being loaded from the same file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 15:58   ` Dan Nicolaescu
  2007-10-21 16:15     ` David Kastrup
@ 2007-10-21 19:38     ` Stefan Monnier
  2007-10-21 23:24       ` Bob Rogers
  2007-10-23  7:12       ` Richard Stallman
  1 sibling, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2007-10-21 19:38 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

>> > With that and with adding a few more (eval-when-compile (require 'blah))
>> What is the use of (eval-when-compile (require 'blah)) in this context?
>> I expect it's the wrong solution.
> When the number of warnings for undefined functions is too high it
> might be better to just require the package that defines them.  But you
> might be right...

The bytecomp.el has code (which ssems not to work any more) that tries to
re-add the warnings in this case (turns the "unknown function" warnings you
get without the `require' into "not sure it'll be defined at runtime" with
the eval-when-compile require).

So it's not the right approach.  `eval-when-compile' should really be used
to require packages that provide a macro or something like that: something
you really need to properly compile the file.

I agree that we need something to turn off specific warnings.  Someone at
some point suggested (defun <foo>) following the same idea as (defvar <foo>).

I think it would be good.  Although I think I'd rather allow the
external-function-delcaration to give an arglist so that the bytecompiler
can check you passed the right number of arguments as well.  So maybe
something like

  (declare-function <foo> <fooarglist>)

would work better.

Along similar lines I'd like to add a

  (require-lazily <feature>)

which would behave similarly to `require' except that the byte-compiler
would replace it with a bunch of autoloads.  so the package would only be
"required" when one of its functions was used.

In any case, for the issue of "dependencies" (e.g. calling
`Info-read-node-name' after `info', or calling `help-buffer' after
`help-setup-xref') I'm not sure what we should ideally do, but the
require-lazily seems like an acceptable solution.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 19:38     ` Stefan Monnier
@ 2007-10-21 23:24       ` Bob Rogers
  2007-10-23  7:12         ` Richard Stallman
  2007-10-23  7:12       ` Richard Stallman
  1 sibling, 1 reply; 19+ messages in thread
From: Bob Rogers @ 2007-10-21 23:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Dan Nicolaescu, emacs-devel

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Sun, 21 Oct 2007 15:38:06 -0400

   . . .

   Along similar lines I'd like to add a

     (require-lazily <feature>)

   which would behave similarly to `require' except that the byte-compiler
   would replace it with a bunch of autoloads.  so the package would only be
   "required" when one of its functions was used.

   In any case, for the issue of "dependencies" (e.g. calling
   `Info-read-node-name' after `info', or calling `help-buffer' after
   `help-setup-xref') I'm not sure what we should ideally do, but the
   require-lazily seems like an acceptable solution.

	   Stefan

Since (IIUC) these are "internal" functions in one package that are
called from another, it seems better to mark them as such at the point
of definition, rather than in some random place in the files that call
them.

   For example, suppose we defined a ";;;API" tag line (or preferably
something less cryptic) to put before the definitions of functions that
are called elsewhere, by analogy with ";;;AUTOLOAD".  Then, a function
like batch-update-autoloads could be written that extracted these tagged
definitions into "declare-function" forms, building an "api-defs.el"
file that would be loaded into batch-byte-compile jobs in order to
suppress the "undefined function" warnings without requiring them to be
loaded.  This also has the benefit of explicitly identifying function
definitions that are used elsewhere within Emacs, despite seeming to be
internal, as a warning to people who might otherwise carelessly change
their interface.

   Given that much, it then ought to be trivial for the byte compiler to
insert

	(or (fbound 'foo-api-function)
	    (require 'foo))

(or something similar to what autoloading does) before the point of call
for each such function, giving the same effect as "require-lazily".

   Note that "api-defs.el" would not be loaded into emacs except when
compiling, nor would it ever be installed.  That way, these "internal
API" functions would remain internal as far as non-Emacs packages are
concerned.

   Thoughts?

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21  9:50 ` martin rudalics
@ 2007-10-22  9:00   ` Richard Stallman
  2007-10-22 20:25     ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Stallman @ 2007-10-22  9:00 UTC (permalink / raw)
  To: martin rudalics; +Cc: dann, emacs-devel

I would like to do something to silence the manu "function is not
known to be defined" warnings that don't correspond to anything wrong.  But
loading another file just for that is too drastic for the purpose.

Perhaps we should add a construct

  (treat-as-defined FILE foo bar)

which would tell the compiler not to warn in this file
about calls to foo and bar -- and have no other effect.

Some special program could scan the sources looking for all these
statements, and then verify that FILE really does define foo and bar.
This could be run during the build process, but not during ordinary
byte compilation.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-22  9:00   ` Richard Stallman
@ 2007-10-22 20:25     ` Eli Zaretskii
  2007-10-23 10:39       ` Richard Stallman
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2007-10-22 20:25 UTC (permalink / raw)
  To: rms; +Cc: rudalics, dann, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 22 Oct 2007 05:00:18 -0400
> Cc: dann@ics.uci.edu, emacs-devel@gnu.org
> 
> Perhaps we should add a construct
> 
>   (treat-as-defined FILE foo bar)
> 
> which would tell the compiler not to warn in this file
> about calls to foo and bar -- and have no other effect.

The name ``treat-as-defined'' is not telling enough what is its
effect.  How about a more general facility, like this:

  (bytecomp-no-warn 'undefined-function FILE FUNC1 FUNC2 ...)

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 19:38     ` Stefan Monnier
  2007-10-21 23:24       ` Bob Rogers
@ 2007-10-23  7:12       ` Richard Stallman
  2007-10-23 14:21         ` Stefan Monnier
  2007-10-23 14:23         ` Stefan Monnier
  1 sibling, 2 replies; 19+ messages in thread
From: Richard Stallman @ 2007-10-23  7:12 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: dann, emacs-devel

    I think it would be good.  Although I think I'd rather allow the
    external-function-delcaration to give an arglist so that the bytecompiler
    can check you passed the right number of arguments as well.  So maybe
    something like

      (declare-function <foo> <fooarglist>)

That seems like a good design, but I think it should also have
the file name, so that something at build time can check all these
against the files they refer to.

    Along similar lines I'd like to add a

      (require-lazily <feature>)

    which would behave similarly to `require' except that the byte-compiler
    would replace it with a bunch of autoloads.  so the package would only be
    "required" when one of its functions was used.

I have a bad feeling about that -- that it would produce scads of autoloads
which are not needed.  Also, I don't think it is needed in any of the existing
cases of warnings we would like to suppress.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-21 23:24       ` Bob Rogers
@ 2007-10-23  7:12         ` Richard Stallman
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-10-23  7:12 UTC (permalink / raw)
  To: Bob Rogers; +Cc: dann, monnier, emacs-devel

       For example, suppose we defined a ";;;API" tag line (or preferably
    something less cryptic) to put before the definitions of functions that
    are called elsewhere, by analogy with ";;;AUTOLOAD".  Then, a function
    like batch-update-autoloads could be written that extracted these tagged
    definitions into "declare-function" forms, building an "api-defs.el"
    file that would be loaded into batch-byte-compile jobs in order to
    suppress the "undefined function" warnings without requiring them to be
    loaded.

This approach could, but putting them in one large file "api-defs.el"
would only do the job if we also make in each file state which other
files it really wants to depend on.  You'd need something like
(compile-require 'foo) to tell the compiler to consider the api-defs
info for foo.

Also, this would only work for calling functions in files
that were scanned by the batch process.  And if you update
those files, you would have to rerun the batch process.

Thus, I think my proposal is better in several ways.
It would be just as reliable, for calls to files checked
by the batch process, but it would not limit you.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-22 20:25     ` Eli Zaretskii
@ 2007-10-23 10:39       ` Richard Stallman
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-10-23 10:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, dann, emacs-devel

    The name ``treat-as-defined'' is not telling enough what is its
    effect.

It seems clear to me.

	     How about a more general facility, like this:

      (bytecomp-no-warn 'undefined-function FILE FUNC1 FUNC2 ...)

It is more cumbersome, and I don't see that we need any more
generality.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-23  7:12       ` Richard Stallman
@ 2007-10-23 14:21         ` Stefan Monnier
  2007-10-24  2:49           ` Richard Stallman
  2007-10-23 14:23         ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2007-10-23 14:21 UTC (permalink / raw)
  To: rms; +Cc: dann, emacs-devel

>       (require-lazily <feature>)

>     which would behave similarly to `require' except that the byte-compiler
>     would replace it with a bunch of autoloads.  so the package would only be
>     "required" when one of its functions was used.

> I have a bad feeling about that -- that it would produce scads of autoloads
> which are not needed.  Also, I don't think it is needed in any of the existing
> cases of warnings we would like to suppress.

The intention is for the byte-compiler to take the intersection of the
functions defined by <feature> and the functions used in the file being
byte-compiled.

So I expect that in general it will not lead to tons of autoloads that are
not needed.  Of course, some of the autoloads will not be needed because
some of those functions will only ever be called after calling another one
of those autoloaded functions (like the example of calling
info-read-node-name after calling `info').  And actually, the byte-compiler
could even optimize away some of those cases.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-23  7:12       ` Richard Stallman
  2007-10-23 14:21         ` Stefan Monnier
@ 2007-10-23 14:23         ` Stefan Monnier
  1 sibling, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2007-10-23 14:23 UTC (permalink / raw)
  To: rms; +Cc: dann, emacs-devel

>     I think it would be good.  Although I think I'd rather allow the
>     external-function-delcaration to give an arglist so that the bytecompiler
>     can check you passed the right number of arguments as well.  So maybe
>     something like

>       (declare-function <foo> <fooarglist>)

> That seems like a good design, but I think it should also have
> the file name, so that something at build time can check all these
> against the files they refer to.

I don't think the <file> argument is important (the build-time check can
just as well read all the files to figure out whether the function is
defined in some file), but it wouldn't hurt, indeed.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-23 14:21         ` Stefan Monnier
@ 2007-10-24  2:49           ` Richard Stallman
  2007-10-24  3:49             ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Richard Stallman @ 2007-10-24  2:49 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: dann, emacs-devel

    The intention is for the byte-compiler to take the intersection of the
    functions defined by <feature> and the functions used in the file being
    byte-compiled.

This requires it to know which functions are defined by that feature.
In other words, compilation would have to USE the table produced
by the batch process.

I prefer the approach I designed, in which the batch process finds
erroneous declarations but its output is not needed to compile
anything.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-24  2:49           ` Richard Stallman
@ 2007-10-24  3:49             ` Stefan Monnier
  2007-10-25  2:10               ` Richard Stallman
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2007-10-24  3:49 UTC (permalink / raw)
  To: rms; +Cc: dann, emacs-devel

>     The intention is for the byte-compiler to take the intersection of the
>     functions defined by <feature> and the functions used in the file being
>     byte-compiled.

> This requires it to know which functions are defined by that feature.
> In other words, compilation would have to USE the table produced
> by the batch process.

Well there would be no separate batch process for it: it's only a change in
the byte-compiler which will treate require-lazy as a normal require during
compilation (i.e. it will load the file during compilation) but will replace
the `require-lazy' by a bunch of autoloads in the .elc file.

It's a different feature than the one you imagine.  Both might be useful.


        Stefan

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: byte compiler warnings when bootstrapping
  2007-10-24  3:49             ` Stefan Monnier
@ 2007-10-25  2:10               ` Richard Stallman
  0 siblings, 0 replies; 19+ messages in thread
From: Richard Stallman @ 2007-10-25  2:10 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: dann, emacs-devel

    Well there would be no separate batch process for it: it's only a change in
    the byte-compiler which will treate require-lazy as a normal require during
    compilation (i.e. it will load the file during compilation) but will replace
    the `require-lazy' by a bunch of autoloads in the .elc file.

Thanks for clarifying, but I think it is a drawback that this needs to
load the other file during compilation.

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2007-10-25  2:10 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-21  7:38 byte compiler warnings when bootstrapping Dan Nicolaescu
2007-10-21  9:50 ` martin rudalics
2007-10-22  9:00   ` Richard Stallman
2007-10-22 20:25     ` Eli Zaretskii
2007-10-23 10:39       ` Richard Stallman
2007-10-21 14:05 ` Stefan Monnier
2007-10-21 15:58   ` Dan Nicolaescu
2007-10-21 16:15     ` David Kastrup
2007-10-21 16:33       ` Dan Nicolaescu
2007-10-21 18:44         ` David Kastrup
2007-10-21 19:38     ` Stefan Monnier
2007-10-21 23:24       ` Bob Rogers
2007-10-23  7:12         ` Richard Stallman
2007-10-23  7:12       ` Richard Stallman
2007-10-23 14:21         ` Stefan Monnier
2007-10-24  2:49           ` Richard Stallman
2007-10-24  3:49             ` Stefan Monnier
2007-10-25  2:10               ` Richard Stallman
2007-10-23 14:23         ` Stefan Monnier

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.