bug#58537: CC Mode 5.35.1 (C/*l); Keywords being fontified as types at random

Hello, Po.

On Sun, Oct 16, 2022 at 15:20:49 +0800, Po Lu via CC-Mode-help wrote:
> Po Lu <[email protected]> writes:

> > Package: cc-mode

> > Sometimes, immediately before typing the closing parentheses of a
> > function invocation, like so:

> > void
> > dm_apply_screen_again (window, drawable, root_x, root_y)
> >      dm_root_window_ptr window;
> >      dm_root_window_drawable_ptr drawable;
> > {
> >   dm_lock_type type;
> >   dm_screen_ptr screen;
> > #if 1
> >   dm_tgs_reply_ptr client_data;
> > #else
> >   caddr_t client_data;
> > #endif
> >   dm_screen_lock_ptr lock;

> >   /* Private code elided.  */

> >   dm_apply_pointer_lock (window, lock

> > every occurrence of "lock", "root_x", and "root_y" in the file becomes
> > fontified as a type, and is stuck that way.  The only way to stop those
> > keywords from being fontified as types is by reenabling c-mode.

Just as a matter of interest, there's a testing hack in CC Mode for this.
Make some buffer change at (point-min), and c-found-types gets
reinitialised.  Maybe I should turn this into a proper command.

> > This did not happen in Emacs 28; I can't reproduce the bug with a file
> > that I can share, but I will keep trying to make one.

> I think I have a reproducible recipe for this now, which I got while
> working on a completely different program.

> First, insert the following text in a buffer:

> RelativePointer *
> XLSeatGetRelativePointer (Seat *seat, struct wl_resource *resource)
> {
>   RelativePointer *relative_pointer;
>   SeatClientInfo *info;

>   /* Create a relative pointer object for the relative pointer
>      resource RESOURCE.  */

>   relative_pointer = XLCalloc (1, sizeof *relative_pointer);
>   info = CreateSeatClientInfo (wl_resource_get_client (resource));

>   /* Link the relative pointer onto the seat client info.  */
>   relative_pointer->next = info->relative_pointers.next;
>   relative_pointer->last = &info->relative_pointers;

>   /* Then, the seat.  */
>   relative_pointer->seat = seat;
>   RetainSeat (seat);
> }

> then, move to the end of the buffer.  Turn on electric-pair-mode and
> c-mode.  Type:

> v SPC o SPC i SPC d RET X L S e a t D e s t r o y R e l a t i v e P o i
> n t e r SPC ( R e l a t i v e P o i n t e r SPC * r e l a t i v e _ p o
> i n t e r C-e

> every occurrence `relative_pointer' will be refontified as a type, and
> become stuck that way.

Thanks for this recipe!  In the end, it turned out to be a flag that
wasn't getting initialised properly.  So after typing a type, it
sometimes stayed set for the next identifier, which became a type, too.

I hope the following patch will have fixed the problem, so would you
please do the usual thing with the patch, and let me know how well the
problem has been fixed.  Thanks!



diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 2003b09ded..fc4e46633b 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -2080,13 +2080,14 @@ c-after-change-fix-comment-escapes
 (defun c-update-new-id (end)
   ;; Note the bounds of any identifier that END is in or just after, in
   ;; `c-new-id-start' and `c-new-id-end'.  Otherwise set these variables to
-  ;; nil.
+  ;; nil.  Set `c-new-id-is-type' unconditionally to nil.
   (save-excursion
     (goto-char end)
     (let ((id-beg (c-on-identifier)))
       (setq c-new-id-start id-beg
 	    c-new-id-end (and id-beg
-			      (progn (c-end-of-current-token) (point)))))))
+			      (progn (c-end-of-current-token) (point)))
+	    c-new-id-is-type nil))))
 
 (defun c-post-command ()
   ;; If point was inside of a new identifier and no longer is, record that



-- 
Alan Mackenzie (Nuremberg, Germany).