GNU bug report logs - #24038
etags missing tag for static prototypes in header file

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 24038 in the body.
You can then email your comments to 24038 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: 312 <moan1223 <at> 163.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: etags missing tag for static prototypes in header file
Date: Wed, 20 Jul 2016 21:39:08 +0800 (GMT+08:00)

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

Hi Everyone,

I found etags fails to create some tags for static method in header file. Is this a known issue.

for example:

etags NestedNameSpecifier.h


lines between 100 and 162 is ignored, those are all static prototype.

Don’t know why this happened.

My emacs version is 25.1.50

Best Regards


Jackson Zheng



 

[Message part 2 (text/html, inline)]

[NestedNameSpecifier.h (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 312 <moan1223 <at> 163.com>
Cc: 24038 <at> debbugs.gnu.org
Subject: Re: bug#24038: etags missing tag for static prototypes in header file
Date: Thu, 21 Jul 2016 17:51:17 +0300

> Date: Wed, 20 Jul 2016 21:39:08 +0800 (GMT+08:00)
> From: 312 <moan1223 <at> 163.com>
> 
> I found etags fails to create some tags for static method in header file. Is this a known issue.
> 
> for example:
> 
> etags NestedNameSpecifier.h
> 
> lines between 100 and 162 is ignored, those are all static prototype.
> Don’t know why this happened.

Thank you for your report.

What is ignored are not static methods, but any method that is not
in-line, i.e. for which you have only the declaration
(a.k.a. "prototype") in the header file, without the implementation.
For example, this method is also missing:

  /// \brief Determine what kind of nested name specifier is stored.
  SpecifierKind getKind() const;

although it isn't declared 'static'.

The reason is that etags by default doesn't tag declarations, on the
assumption that the user wants to see the definitions of the methods,
not their prototypes.  If you want declarations included, you need to
invoke etags with the --declarations option.  (That will also tag
global variables, so if you don't want that, use --no-globals as
well.)

IOW, this is not a bug, but the expected behavior.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 312 <moan1223 <at> 163.com>, 24038 <at> debbugs.gnu.org
Subject: Re: bug#24038: etags missing tag for static prototypes in header file
Date: Sun, 29 Sep 2019 06:57:42 +0200

tags 24038 + notabug
close 24038
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Wed, 20 Jul 2016 21:39:08 +0800 (GMT+08:00)
>> From: 312 <moan1223 <at> 163.com>
>>
>> I found etags fails to create some tags for static method in header file. Is this a known issue.
>>
>> for example:
>>
>> etags NestedNameSpecifier.h
>>
>> lines between 100 and 162 is ignored, those are all static prototype.
>> Don¡¯t know why this happened.
>
> Thank you for your report.
>
> What is ignored are not static methods, but any method that is not
> in-line, i.e. for which you have only the declaration
> (a.k.a. "prototype") in the header file, without the implementation.
> For example, this method is also missing:
>
>   /// \brief Determine what kind of nested name specifier is stored.
>   SpecifierKind getKind() const;
>
> although it isn't declared 'static'.
>
> The reason is that etags by default doesn't tag declarations, on the
> assumption that the user wants to see the definitions of the methods,
> not their prototypes.  If you want declarations included, you need to
> invoke etags with the --declarations option.  (That will also tag
> global variables, so if you don't want that, use --no-globals as
> well.)
>
> IOW, this is not a bug, but the expected behavior.

Eli indicates above that this is expected behaviour.  I'm therefore
closing this as notabug.

If that's incorrect, please reopen.

Best regards,
Stefan Kangas

Previous Next

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