bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>> Cc: 45751@debbugs.gnu.org
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> > Compiling
>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>> 
>> I see a similar issue with sanityinc-tomorrow.el, the compilation is way
>> slower than any other one but it completes eventually.  I guess is the
>> same issue you see and with sufficient RAM also sanityinc-solarized
>> should complete.
>> 
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function that after
>> macro expansion becomes enormous.
>> 
>> We need to make the compiler robust against these corner cases, I'll
>> have a look this week into adding some logic for that.
>
> Maybe we should have a "no-native-compile" cookie for these cases.
> After all, compiling a theme will not really speed up anything
> important, right?

Agreed, that's a good idea.

At the moment similar mechanisms are:

- Declare a function with (declare (speed -1)) will include the
  function in the .eln but in byte-code form.

- Have comp-speed to -1 as file variable in the source file should
  produce an eln containing only byte-code functions.

But yeah, a dedicated cookie is better because there's no point of
producing the .eln file at all for cases like this.

  Andrea