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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64322 in the body.
You can then email your comments to 64322 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Wed, 28 Jun 2023 15:05:03 +0800

Package: cc-mode

I just encountered a new instance of CC Mode misrecognizing identifiers
as types.  In a C Mode buffer, insert:

void
add_property (name, expression)

then, type:

RET TAB s t r u c t SPC e x p r e s s i o n SPC e x p r e s s i o n ;

`expression' will then be fontified as a type within the function
declarator's identifier list!

Thanks in advance.

Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu)
 of 2023-06-25
Package: CC Mode 5.35.2 (C/*l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

current state:
==============
(setq
 c-basic-offset 2
 c-comment-only-line-offset '(0 . 0)
 c-indent-comment-alist '((anchored-comment column . 0) (end-block space . 1) (cpp-end-block space . 2))
 c-indent-comments-syntactically-p nil
 c-block-comment-prefix ""
 c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+") (other . "//+\\|\\**"))
 c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc) (c-mode . gtkdoc) (c++-mode . gtkdoc))
 c-cleanup-list '(scope-operator)
 c-hanging-braces-alist '((substatement-open before after) (arglist-cont-nonempty))
 c-hanging-colons-alist nil
 c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
 c-backslash-column 48
 c-backslash-max-column 72
 c-special-indent-hook '(t c-gnu-impose-minimum)
 c-label-minimum-indentation 1
 c-offsets-alist '((inexpr-class . +)
		   (inexpr-statement . +)
		   (lambda-intro-cont . +)
		   (inlambda . 0)
		   (template-args-cont c-lineup-template-args +)
		   (incomposition . +)
		   (inmodule . +)
		   (innamespace . +)
		   (inextern-lang . +)
		   (composition-close . 0)
		   (module-close . 0)
		   (namespace-close . 0)
		   (extern-lang-close . 0)
		   (composition-open . 0)
		   (module-open . 0)
		   (namespace-open . 0)
		   (extern-lang-open . 0)
		   (objc-method-call-cont c-lineup-ObjC-method-call-colons c-lineup-ObjC-method-call +)
		   (objc-method-args-cont . c-lineup-ObjC-method-args)
		   (objc-method-intro . [0])
		   (friend . 0)
		   (cpp-define-intro c-lineup-cpp-define +)
		   (cpp-macro-cont . +)
		   (cpp-macro . [0])
		   (inclass . +)
		   (stream-op . c-lineup-streamop)
		   (arglist-cont-nonempty c-lineup-gcc-asm-reg c-lineup-arglist)
		   (arglist-cont c-lineup-gcc-asm-reg 0)
		   (comment-intro c-lineup-knr-region-comment c-lineup-comment)
		   (catch-clause . 0)
		   (else-clause . 0)
		   (do-while-closure . 0)
		   (access-label . -)
		   (case-label . 0)
		   (substatement . +)
		   (statement-case-intro . +)
		   (statement . 0)
		   (brace-entry-open . 0)
		   (brace-list-entry . 0)
		   (brace-list-close . 0)
		   (block-close . 0)
		   (block-open . 0)
		   (inher-cont . c-lineup-multi-inher)
		   (inher-intro . +)
		   (member-init-cont . c-lineup-multi-inher)
		   (member-init-intro . +)
		   (annotation-var-cont . +)
		   (annotation-top-cont . 0)
		   (topmost-intro . 0)
		   (knr-argdecl . 0)
		   (func-decl-cont . +)
		   (inline-close . 0)
		   (class-close . 0)
		   (class-open . 0)
		   (defun-block-intro . +)
		   (defun-close . 0)
		   (defun-open . 0)
		   (c . c-lineup-C-comments)
		   (string . c-lineup-dont-change)
		   (topmost-intro-cont first c-lineup-topmost-intro-cont c-lineup-gnu-DEFUN-intro-cont)
		   (brace-list-intro first c-lineup-2nd-brace-entry-in-arglist c-lineup-class-decl-init-+ +)
		   (brace-list-open . +)
		   (inline-open . 0)
		   (arglist-close . c-lineup-arglist)
		   (arglist-intro . c-lineup-arglist-intro-after-paren)
		   (statement-cont . +)
		   (statement-case-open . +)
		   (label . 0)
		   (substatement-label . 0)
		   (substatement-open . +)
		   (knr-argdecl-intro . 5)
		   (statement-block-intro . +)
		   )
 c-buffer-is-cc-mode 'c-mode
 c-tab-always-indent t
 c-syntactic-indentation t
 c-syntactic-indentation-in-macros t
 c-ignore-auto-fill '(string cpp code)
 c-auto-align-backslashes t
 c-backspace-function 'backward-delete-char-untabify
 c-delete-function 'delete-char
 c-electric-pound-behavior nil
 c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
 c-enable-xemacs-performance-kludge-p nil
 c-old-style-variable-behavior nil
 defun-prompt-regexp nil
 tab-width 8
 comment-column 32
 parse-sexp-ignore-comments t
 parse-sexp-lookup-properties t
 auto-fill-function nil
 comment-multi-line t
 comment-start-skip "\\(?://+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 70
 paragraph-start "[ 	]*\\(//+\\|\\**\\)[ 	]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ 	]*\\(//+\\|\\**\\)[ 	]*\\([ 	]*\\([-–!|#%;>*·•‣⁃◦]+[ 	]*\\)*\\)"
 )

Message #8 received at 64322 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 64322 <at> debbugs.gnu.org
Subject: Re: bug#64322: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Fri, 30 Jun 2023 19:47:05 +0000

[Message part 1 (text/plain, inline)]

Hello, Po.

On Wed, Jun 28, 2023 at 15:05:03 +0800, Po Lu via CC-Mode-help wrote:
> Package: cc-mode

> I just encountered a new instance of CC Mode misrecognizing identifiers
> as types.  In a C Mode buffer, insert:

> void
> add_property (name, expression)

> then, type:

> RET TAB s t r u c t SPC e x p r e s s i o n SPC e x p r e s s i o n ;

> `expression' will then be fontified as a type within the function
> declarator's identifier list!

Yes.  The problem was a confusion between C++ and C regarding type
definition.  In C++, "class Foo" or "struct Foo" defines a type "Foo".
In C, in "struct Foo", there is no such type defined, "Foo" is merely a
struct tag.

This involves a one line fix in cc-langs.el, to remove items from the
lang const c-typeless-decl-kwds.  Additionally, I've corrected an
unrelated typo in cc-fonts.el.

Would you please try out the attached patch in your real code
thoroughly, and either confirm the bug is fixed, or tell me what's still
wrong.  Thanks!

> Thanks in advance.

> Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu)
>  of 2023-06-25
> Package: CC Mode 5.35.2 (C/*l)
> Buffer Style: gnu
> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

-- 
Alan Mackenzie (Nuremberg, Germany).

[diff.20230630.diff (text/plain, attachment)]

Message #11 received at 64322 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64322 <at> debbugs.gnu.org
Subject: Re: bug#64322: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Sat, 01 Jul 2023 08:22:41 +0800

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

> Hello, Po.
>
> On Wed, Jun 28, 2023 at 15:05:03 +0800, Po Lu via CC-Mode-help wrote:
>> Package: cc-mode
>
>> I just encountered a new instance of CC Mode misrecognizing identifiers
>> as types.  In a C Mode buffer, insert:
>
>> void
>> add_property (name, expression)
>
>> then, type:
>
>> RET TAB s t r u c t SPC e x p r e s s i o n SPC e x p r e s s i o n ;
>
>> `expression' will then be fontified as a type within the function
>> declarator's identifier list!
>
> Yes.  The problem was a confusion between C++ and C regarding type
> definition.  In C++, "class Foo" or "struct Foo" defines a type "Foo".
> In C, in "struct Foo", there is no such type defined, "Foo" is merely a
> struct tag.
>
> This involves a one line fix in cc-langs.el, to remove items from the
> lang const c-typeless-decl-kwds.  Additionally, I've corrected an
> unrelated typo in cc-fonts.el.
>
> Would you please try out the attached patch in your real code
> thoroughly, and either confirm the bug is fixed, or tell me what's still
> wrong.  Thanks!
>
>> Thanks in advance.
>
>> Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu)
>>  of 2023-06-25
>> Package: CC Mode 5.35.2 (C/*l)
>> Buffer Style: gnu
>> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

Seems to work here, thanks.  Eli, could we have this on the emacs-29
branch?

Message #14 received at 64322 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: acm <at> muc.de, 64322 <at> debbugs.gnu.org
Subject: Re: bug#64322: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Sat, 01 Jul 2023 10:10:45 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 64322 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 01 Jul 2023 08:22:41 +0800
> 
> Alan Mackenzie <acm <at> muc.de> writes:
> 
> > Yes.  The problem was a confusion between C++ and C regarding type
> > definition.  In C++, "class Foo" or "struct Foo" defines a type "Foo".
> > In C, in "struct Foo", there is no such type defined, "Foo" is merely a
> > struct tag.
> >
> > This involves a one line fix in cc-langs.el, to remove items from the
> > lang const c-typeless-decl-kwds.  Additionally, I've corrected an
> > unrelated typo in cc-fonts.el.
> >
> > Would you please try out the attached patch in your real code
> > thoroughly, and either confirm the bug is fixed, or tell me what's still
> > wrong.  Thanks!
> >
> >> Thanks in advance.
> >
> >> Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu)
> >>  of 2023-06-25
> >> Package: CC Mode 5.35.2 (C/*l)
> >> Buffer Style: gnu
> >> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)
> 
> Seems to work here, thanks.  Eli, could we have this on the emacs-29
> branch?

Yes, if Alan is okay with making this change on the release branch.

Message #17 received at 64322 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, acm <at> muc.de, 64322 <at> debbugs.gnu.org
Subject: Re: bug#64322: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Sat, 1 Jul 2023 10:43:30 +0000

Hello, Eli.

On Sat, Jul 01, 2023 at 10:10:45 +0300, Eli Zaretskii wrote:
> > From: Po Lu <luangruo <at> yahoo.com>
> > Cc: 64322 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> > Date: Sat, 01 Jul 2023 08:22:41 +0800

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

> > > Yes.  The problem was a confusion between C++ and C regarding type
> > > definition.  In C++, "class Foo" or "struct Foo" defines a type "Foo".
> > > In C, in "struct Foo", there is no such type defined, "Foo" is merely a
> > > struct tag.

> > > This involves a one line fix in cc-langs.el, to remove items from the
> > > lang const c-typeless-decl-kwds.  Additionally, I've corrected an
> > > unrelated typo in cc-fonts.el.

> > > Would you please try out the attached patch in your real code
> > > thoroughly, and either confirm the bug is fixed, or tell me what's still
> > > wrong.  Thanks!

> > >> Thanks in advance.

> > >> Emacs  : GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu)
> > >>  of 2023-06-25
> > >> Package: CC Mode 5.35.2 (C/*l)
> > >> Buffer Style: gnu
> > >> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

> > Seems to work here, thanks.  Eli, could we have this on the emacs-29
> > branch?

> Yes, if Alan is okay with making this change on the release branch.

My yesterday's patch amended C Mode and Objective-C Mode.  I'm now less
sure about the Objective-C Mode change than I was yesterday.  So I
propose changing only C Mode.

Yes, I will do this on the release branch today.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #22 received at 64322-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: acm <at> muc.de, 64322-done <at> debbugs.gnu.org
Subject: Re: bug#64322: CC Mode 5.35.2 (C/*l); More incorrect type recognition
Date: Sat, 1 Jul 2023 11:25:42 +0000

Hello, Po and Eli.

On Sat, Jul 01, 2023 at 10:43:30 +0000, Alan Mackenzie wrote:
> On Sat, Jul 01, 2023 at 10:10:45 +0300, Eli Zaretskii wrote:
> > > From: Po Lu <luangruo <at> yahoo.com>
> > > Cc: 64322 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> > > Date: Sat, 01 Jul 2023 08:22:41 +0800

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

[ .... ]

> > > > Would you please try out the attached patch in your real code
> > > > thoroughly, and either confirm the bug is fixed, or tell me
> > > > what's still wrong.  Thanks!

[ .... ]

> > > Seems to work here, thanks.  Eli, could we have this on the emacs-29
> > > branch?

> > Yes, if Alan is okay with making this change on the release branch.

> My yesterday's patch amended C Mode and Objective-C Mode.  I'm now less
> sure about the Objective-C Mode change than I was yesterday.  So I
> propose changing only C Mode.

> Yes, I will do this on the release branch today.

DONE.  I'm closing the bug with this post.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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