GNU bug report logs -
#25623
CC Mode 5.32.99 (C/l); `c-defun-name' returns wrong result for filescope enums, structs and unions
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 12 Jul 2017 20:24:53 +0000
with message-id <20170712202453.GB13295 <at> acm>
and subject line Re: bug#25623: CC Mode 5.32.99 (C/l); `c-defun-name' returns wrong result for filescope enums, structs and unions
has caused the debbugs.gnu.org bug report #25623,
regarding CC Mode 5.32.99 (C/l); `c-defun-name' returns wrong result for filescope enums, structs and unions
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
25623: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25623
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
When the point is in struct, enum or union of file scope, `c-defun-name'
returns wrong result.
Eg: In the following example (where `|' is where the points are (ie, 3
cursors are 3 different cases),
case 1, in struct: the result is "t" ("struct test" may be a better
result, the same for union)
case 2, in enum: the result is "ONE" ("enum" may be better)
case 3, in main: the result is "main" (which is of course, right)
Also, simply return "struct", "union", etc if no tag name is present
(like in "typedef struct {...")
struct test
{
int a;|
};
enum {
ONE,
TWO|
};
int
main (void)
{
|
}
Thanks
Emacs : GNU Emacs 26.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.6)
of 2017-01-20
Package: CC Mode 5.32.99 (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 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-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 '(c-gnu-impose-minimum)
c-label-minimum-indentation 1
c-offsets-alist '((inexpr-class . +)
(inexpr-statement . +)
(lambda-intro-cont . +)
(inlambda . c-lineup-inexpr-block)
(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-intro . +)
(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-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 part 3 (message/rfc822, inline)]
Hello, Mohammed.
On Mon, Apr 24, 2017 at 09:14:27 +0530, Mohammed Sadiq wrote:
> > On April 24, 2017 at 2:31 AM Alan Mackenzie <acm <at> muc.de> wrote:
> > > enum
> > > {
> > > A,
> > > B,|
> > > C,
> > > };
> > > gives 'nil', which would better return 'enum' as it is common to have enums without
> > > names associated.
> > I've thought about this. The problem is that "enum" is not a name - it
> > is a keyword.
> Yeah, right, but as "enum" and "struct" can't be used function names, users can use
> c-defun-name to check if the point is in struct or enum too.
I put on my (hopefully benevolent) dictator's hat and decided to stick
with my reasoning, here.
> > > int a[] = {'h', 'e', 'l', 'l', 'o', '\0'|};
> > > gives "[" which I believe, should actually return 'nil' when defined at file scope.
> > It should indeed return nil. Please see the amended patch (below).
> Your patch fixed the issue.
Thanks. I've committed the patch and closed the bug.
> > > typedef struct
> > > {
> > > int a;
> > > int b;|
> > > } nice;
> > > returns "nice". It may be better to return "struct nice" as in "struct nice {...};" definition.
> > I considered that, too. Even returning "nice" is a bit bogus, here. For
> > example, if we had "typedef struct { ... } nice, easy;" why should we
> > return "nice" (which we do) rather than "easy"? I think here, strictly
> > speaking, we should return nil, since "nice" is an identifier _after_ the
> > main type definition, not part of it. But, then again, maybe here is not
> > the place to be strict. ;-)
> If in both cases, returning simply "struct" would be more helpful to the users
> than nil, imho. the same for enum
I'm afraid I used my dictator's hat here, too.
Anyway, the bug is, at long last, closed.
> Thanks
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 8 years and 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.