GNU bug report logs - #60769
CC Mode 5.35.2 (C/*l); More incorrect type recognition

Previous Next

Package: cc-mode;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Fri, 13 Jan 2023 03:03:01 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 60769 <at> debbugs.gnu.org
Subject: bug#60769: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Wed, 18 Jan 2023 15:24:15 +0000
[Message part 1 (text/plain, inline)]
Hello, Po.

On Tue, Jan 17, 2023 at 13:16:22 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > Hello, Po.

> > On Fri, Jan 13, 2023 at 11:01:44 +0800, Po Lu via CC-Mode-help wrote:
> >> Package: cc-mode

> >> Here is another example of incorrect type recognition in C Mode as a
> >> result of a typo:

> >> static Lisp_Object
> >> frame_geometry (Lisp_Object frame, Lisp_Object attribute)
> >> {
> >>   struct frame *f = decode_live_frame (frame);
> >>   /**   XWindowAttributes atts; **/
> >>   Window rootw;
> >>   unsigned int ign, native_width, native_height, x_border_width = 0;
> >>   int x_native = 0, y_native = 0, xptr = 0, yptr = 0;
> >>   int left_off = 0, right_off = 0, top_off = 0, bottom_off = 0;
> >>   int outer_left, outer_top, outer_right, outer_bottom;
> >>   int native_left, native_top, native_right, native_bottom;
> >>   int inner_left, inner_top, inner_right, inner_bottom;
> >>   int internal_border_width;
> >>   bool menu_bar_external = false, tool_bar_external = false;
> >>   int menu_bar_height = 0, menu_bar_width = 0;
> >>   int tab_bar_height = 0, tab_bar_width = 0;
> >>   int tool_bar_height = 0, tool_bar_width = 0;

> >>   if (FRAME_INITIAL_P (f) || !FRAME_ANDROID_P (f)
> >>       || !FRAME_ANDROID_WINDOW (f))
> >>     return Qnil;

> >>   block_input ();
> >>   android_get_geometry (FRAME_ANDROID_WINDOW (f),
> >> 			&rootw, &x_native, &y_native,
> >> 			&native_width, &native_height, &x_border_width,
> >> 			&ign);
> >>   unblock_input ();
> >> }

> >> Place point after "android_get_geometry (", and accidentally type:

> >>   d

> >> (this was meant to be C-M-d.)

> >> Now, FRAME_ANDROID_WINDOW and android_get_geometry are stuck in
> >> c-found-types.

> > I'm afraid I can't reproduce this on either master or emacs-29.  Am I
> > correct in assuming that you mean insert the one single character "d"
> > after the "(" in that line?  Even when I additionally insert a space,
> > M-: (c-list-found-types) just lists "Window", which seems correct.

> Sorry for the confusion, Alan.  I meant to insert the character "d"
> immediately before "(".

Ah!  Yes, that's different.  ;-)

I can now reproduce the bug, and analysing it, it actually turned out to
be two distinct cases, one for android_get_geometry and the other for
FRAME_ANDROID_WINDOW.  I've fixed both of them with the now familiar
"unsafe-maybe" mechanism.

Would you please do the usual with the attached patch, and let me know if
anything is amiss.  In particular, if you notice any types which were
(correctly) fontified as types, but now no longer get fontified, please
tell me.  Thanks!

I look forward to hearing from you again.

-- 
Alan Mackenzie (Nuremberg, Germany).


> Thanks.
[diff.20230118.diff (text/plain, attachment)]

This bug report was last modified 2 years and 123 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.