bug#45198: 28.0.50; Sandbox mode

[João Távora]

On Sat, Dec 19, 2020 at 6:47 PM Mattias Engdegård <mattiase@acm.org> wrote:
>
> 19 dec. 2020 kl. 19.11 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>
> > I must say I don't know what's being discussed here.
> > What autoloads?  Why do we care?
>
> If a user looks at elisp code that depends on autoloads and the checker 
> process cannot load those for reasons of sandbox policy or whatnot, there 
> will be false positives about missing functions. This is fine if we are 
> phasing out autoloads but as far as I know we're not.

It would have to depend on autoloads at compilation time.  As far as
I can tell, that's not extremely common.  It's quite more common
that things are `require`d and thus `load`ed at compilation time,
so if we block that, the Flymake compilation output becomes quite
useless in most cases, producing big single error in that first require.

Such things can and already do happen with processes that
have non-standard  load-paths mechanisms, such as one of mine.
The only load-path that the Flymake currently sees is the current
directory's.  I suppose extending that is possible (and it's been in my
plans). It's also possibly another "hazard", though one incurred in
consciously by the user,  whom we may warn via the usual "unsafe
local variables" machinery.

João