bug#60691: 29.0.60; Slow tree-sitter font-lock in ruby-ts-mode

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 60691@debbugs.gnu.org, juri@linkov.net
> Date: Fri, 13 Jan 2023 01:40:56 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> Managed to reproduce this after running the test in a couple of 
> different files.
> 
> But 'M-x memory-usage' says no such command, and 'M-x memory-report' 
> ends up with this error:
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>    memory-report--gc-elem(nil strings)
>    memory-report--garbage-collect()
>    memory-report()

This means GC is disabled in this session at the time you invoke
memory-report.  Which shouldn't happen, of course.  It sounds like
your pure Lisp storage overflowed, and that disabled GC.

And I think I see the problem: we use build_pure_c_string in treesit.c
in places that we shouldn't.

Yuan, build_pure_c_string should only be used in places such as
syms_of_treesit, which are called just once, during dumping.  Look at
all the other calls to this function in the sources, and you will see
it.  In all other cases, you should do one of the following:

  . for strings whose text is fixed, define a variable, give it the
    value in syms_of_treesit using build_pure_c_string, then use that
    variable elsewhere in the source
  . for strings whose text depends on run-time information, use
    AUTO_STRING or build_string

This is a serious problem, and we should fix it ASAP.

> garbage-collect's docstring says:
> 
>    However, if there was overflow in pure space, and Emacs was dumped
>    using the "unexec" method, ‘garbage-collect’ returns nil, because
>    real GC can’t be done.
> 
> I don't know if my Emacs was dumped using "unexec", though. ./configure 
> says I'm using pdumper.

The above text doesn't account for bugs ;-)  Functions that produce
objects in pure space are supposed to be called only during the build,
a.k.a. "when dumping", and for that the text is correct.