bug#10664: 24.0.93; JIT font-lock infloops in a C file

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan.

On Tue, Feb 07, 2012 at 06:39:11PM -0500, Stefan Monnier wrote:
> > For one particular fontification in socket.c, the "safe position" is 500
> > bytes back from the starting point, so jit-lock is pushed back these 500
> > bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
> > new start position set back 500 bytes, rinse, spin, repeat.

> Why is "jit-lock pushed back"?

Build Emacs revision #106728.  emacs -Q, then create the following C++
buffer:

#########################################################################
1 template <typename T>
2
3
4 void myfunc(T* p) {}
#########################################################################

This is fontified correctly.  Type a space on L2.  This is OK for half a
second, then context fontification messes up L4.  The correct
fontification can only be restored by a change to L4.

Revision #106729 fixes this problem, after a space on L2, by making the
fontification start at L1 rather than L2.

The exact mechanism of why the problem happened is buried in my log, and
I could dredge it up if you're really interested.

The problem with this approach is demonstrated in Eli's socket.c:

SCM_DEFINE (scm_inet_pton, "inet-pton", 2, 0, 0,
            (SCM family, SCM address),
            "Convert a string containing a printable network address to\n"
            "an integer address.  Note that unlike the C version of this\n"
            "function,\n"
            "the result is an integer with normal host byte ordering.\n"
            "@var{family} can be @code{AF_INET} or @code{AF_INET6}.  E.g.,\n\n"
            "@lisp\n"
            "(inet-pton AF_INET \"127.0.0.1\") @result{} 2130706433\n"
            "(inet-pton AF_INET6 \"::1\") @result{} 1\n"
            "@end lisp")
#define FUNC_NAME s_scm_inet_pton
{

A 500 byte chunk of fontification ends just before "@end lisp".  For
this line, the start of the next chunk is "pushed back" to the
SCM_DEFINE line to get a proper context for "@end lisp".  It then
repeatedly fontifies the same chunk.

Interestingly, EOL just before "@end lisp" is exactly 500 bytes after
the initial scm_inet_pton.

-- 
Alan Mackenzie (Nuremberg, Germany).