bug#45198: 28.0.50; Sandbox mode

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> It was suggested that no init files be loaded to make the Emacs subprocess
>>> start faster. (I'm neutral here.)
>> I still have no idea what this has to do with autoloads.
> If Emacs does not read the user's init file in the checking process, then
> autoloads for external packages are not defined and the byte-compiler will
> complain when encountering calls to functions defined in external packages
> not explicitly required. Other people seem to believe it's not a big deal;
> I'm unsure.

Oh, I think I see what you mean.  I suspect that "autoload" is not the
crux of the matter (and "init file" isn't either) and we'll only know
how important the issue is and how best to fix it with more experience.
E.g. maybe the better option will be for `elisp-flymake-byte-compile` to
try and pass down some of that contextual info
(e.g. `package-directory-list` and `load-path`) to the subprocess, or
maybe we'll want `elisp-flymake-byte-compile` to recognize the
`Package-Requires:` header, ...

I think the more important pressing issue will be to distinguish "config
file" (i.e. packages whose main purpose is to change the behavior of
Emacs when they're loaded) from "ELisp package file" (packages which,
according to the coding convention, should not change the behavior of
Emacs when loaded), since config files are likely to be full of false
positives that can't be conveniently fixed by the user whereas for
genuine ELisp package files we have a range of tools to fix
the warnings.


        Stefan