bug#74966: 31.0.50; Crash report (using igc on macOS)

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

>> Maybe the problem is in store_doc_string (doc.c:469 here), not sure.
>> That function does
>>
>>   if (SUBRP (fun))
>>     XSUBR (fun)->doc = offset;

Sounds right.

> That seems to be the cause, indeed. When I 
>
> 1 file changed, 4 insertions(+), 1 deletion(-)
> src/doc.c | 5 ++++-
>
> modified   src/doc.c
> @@ -479,7 +479,10 @@ store_function_docstring (Lisp_Object obj, EMACS_INT offset)
>      fun = XCDR (fun);
>    /* Lisp_Subrs have a slot for it.  */
>    if (SUBRP (fun))
> -    XSUBR (fun)->doc = offset;
> +    {
> +      if (!NATIVE_COMP_FUNCTIONP (fun))
> +	XSUBR (fun)->doc = offset;
> +    }
>    else if (CLOSUREP (fun))
>      {
>        /* This bytecode object must have a slot for the docstring, since
>
> I don't get the assert anymore.

`offset` here should be fixnum that gives the position of this docstring
in the DOC file.  And FUN should be a function for which we found
a DEFUN in one of the C files.  So in general it should be
a `primitive-function`.  We have a few undesirable cases where
a function is defined in C code for some platforms and in ELisp for
others, which is why there's the `CLOSUREP (fun)` branch

If those rare CLOSUREs get native-compiled, then we'll use the SUBRP
branch, of course, but I have no idea why that would lead to a crash.
We're talking about a fixnum so that's usually quite safe w.r.t GC
and crashes.


        Stefan