Below update is after I updated to the latest org master:

On Thu, May 25, 2017 at 10:53 PM Kyle Meyer <kyle@kyleam.com> wrote:

> Ah, right ... 'make compile' uses a single Emacs instance, while 'make
> single' uses a separate Emacs instance for each file.
>

I wasn't even doing that. I was doing M-x byte-compile-file and selecting
org.el.

That gives me (without applying your patch):

Compiling file
/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/org-mode/lisp/org.el
at Fri May 26 14:04:52 2017

In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
    takes 0

In org-todo:
org.el:12398:12:Warning: function org-todo used to take 0+ arguments, now
    takes 0-1

In org-store-log-note:
org.el:13635:8:Warning: function org-store-log-note used to take 0+
arguments,
    now takes 0

In org-at-timestamp-p:
org.el:17909:40:Warning: reference to free variable
    ‘org-agenda-include-inactive-timestamps’

In org-self-insert-command:
org.el:19910:32:Warning: function org-self-insert-command used to take 0+
    arguments, now takes 1

With 'make single' on master, I get a compile error due to the
> eval-when-compile's added in 53ee147f4 (Add support for new switches to
> org-get-heading, 2017-01-17) and 6dc6eb3b0 (Fix failing test,
> 2017-01-19).


>     In toplevel form:
>     org.el:7914:51:Error: Symbol’s value as variable is void:
> org-comment-string
>

I get that too.


> Your patch is only the appropriate fix if we're confident that
> org-agenda will be loaded at the time that the
> org-agenda-include-inactive-timestamps code path of org-at-timestamp-p
> is executed.  Otherwise, we're just silencing a warning about a possible
> run-time void variable error.  Have you looked this?


No, I didn't.. your bound-and-true-p patch makes more sense.

So.. should we consider the warnings output by simple byte-compile-file?
Even if not, the warnings do not make sense.. just taking this example:

In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
    takes 0

Nowhere is org-goto-map defined to take 0+ arguments (meaning have
"&optional arg" as signature) and then redefined to have 0 arguments (which
is the actual case). Wondering why the compiler thinks that. I had a quick
look at byte-compile-arglist-warn function that outputs this warning.. but
couldn't understand the logic for sig1 in there.
-- 

Kaushal Modi