bug#57972: 29.0.50; Autoloaded function raises (void-function org-element-cache-reset) when called within major-mode body

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Wed, 21 Sep 2022 22:51:16 +0800
> Cc: 57972@debbugs.gnu.org
> 
>  And another thing: do you have any clue (or maybe more than a clue)
>  what changes in Org wrt what's on the Emacs master branch could have
>  caused this?  If you do, can you show those changes, or point to the
>  specific places in Org files where those changes can be eye-balled?
> 
> I bisected Org repo and found the first bad commit. Unfortunately, it is not 
> very useful.
> 
> The commit changed the order function calls in org-mode. Before the commit, 
> `org-setup-filling' got called prior to `org-element-cache-reset' and
>  `org-setup-filling' has an explicit (require 'org-element) statement, which
>   made autoloading unnecessary in the past. 

OK, that explains the problem, I think.

> I can generate an alternative backtrace using debug-on-entry org-mode.
> The debug buffer right before error is below

Thanks.  However, even before I look deeper into the backtrace, it
sounds like the problem looks us right in our face.  The snippet from
org.el I posted earlier, i.e.

  (or (eq this-command 'eval-buffer)  <<<<<<<<<<<<<<<<<<<<<
      (condition-case nil
          (load (concat (file-name-directory load-file-name)
                        "org-loaddefs")
                nil t nil t)
        (error
         (message "WARNING: No org-loaddefs.el file could be found from where 
org.el is loaded.")
         (sit-for 3)
         (message "You need to run \"make\" or \"make autoloads\" from Org lisp 
directory")
         (sit-for 3))))

explicitly avoids loading org-loaddefs.el if org.el was loaded via
eval-buffer.  Which is exactly the case here, isn't it, and explains
why the loaddefs aren't loaded?

So now the question becomes: why does org.el treat eval-buffer in this
special way?  Perhaps because of byte-compilation or something?