GNU bug report logs - #38511
etags seems to be confused by macros

Previous Next

Package: emacs;

Reported by: Skip Montanaro <skip.montanaro <at> gmail.com>

Date: Fri, 6 Dec 2019 20:31:02 UTC

Severity: normal

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Fri, 06 Dec 2019 20:31:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Skip Montanaro <skip.montanaro <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 06 Dec 2019 20:31:02 GMT) Full text and rfc822 format available.

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

From: Skip Montanaro <skip.montanaro <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: etags seems to be confused by macros
Date: Fri, 6 Dec 2019 14:20:14 -0600
I use speedbar in Emacs, which relies on etags to generate tag files.
The Python source defines a macro named Py_LOCAL_INLINE, which is used
to select the appropriate spelling of "static inline":

#if defined(_MSC_VER)
...
#  define Py_LOCAL_INLINE(type) static __inline type __fastcall
#else
...
#  define Py_LOCAL_INLINE(type) static inline type
#endif

It's used like so:

Py_LOCAL_INLINE(void)
stackdepth_push(basicblock ***sp, basicblock *b, int depth)
{
    assert(b->b_startdepth < 0 || b->b_startdepth == depth);
    if (b->b_startdepth < depth && b->b_startdepth < 100) {
        assert(b->b_startdepth < 0);
        b->b_startdepth = depth;
        *(*sp)++ = b;
    }
}

It all works well. Etags though, thinks the file contains a function
named "Py_LOCAL_INLINE" and completely misses the actual function,
"stackdepth_push".

Seems like a bug to me, but it's not obvious if there is a trivial
fix. As a workaround, I think I can write a little shell script which
effectively expands the Py_LOCAL_INLINE macro, then pumps the result
to etags. Still, would be kind of nice if this could be fixed.

Thanks,

Skip Montanaro




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Sun, 08 Dec 2019 06:09:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Skip Montanaro <skip.montanaro <at> gmail.com>
Cc: 38511 <at> debbugs.gnu.org
Subject: Re: bug#38511: etags seems to be confused by macros
Date: Sat, 07 Dec 2019 09:14:39 +0200
> From: Skip Montanaro <skip.montanaro <at> gmail.com>
> Date: Fri, 6 Dec 2019 14:20:14 -0600
> 
> I use speedbar in Emacs, which relies on etags to generate tag files.
> The Python source defines a macro named Py_LOCAL_INLINE, which is used
> to select the appropriate spelling of "static inline":
> 
> #if defined(_MSC_VER)
> ...
> #  define Py_LOCAL_INLINE(type) static __inline type __fastcall
> #else
> ...
> #  define Py_LOCAL_INLINE(type) static inline type
> #endif
> 
> It's used like so:
> 
> Py_LOCAL_INLINE(void)
> stackdepth_push(basicblock ***sp, basicblock *b, int depth)
> {
>     assert(b->b_startdepth < 0 || b->b_startdepth == depth);
>     if (b->b_startdepth < depth && b->b_startdepth < 100) {
>         assert(b->b_startdepth < 0);
>         b->b_startdepth = depth;
>         *(*sp)++ = b;
>     }
> }
> 
> It all works well. Etags though, thinks the file contains a function
> named "Py_LOCAL_INLINE" and completely misses the actual function,
> "stackdepth_push".

Etags works by looking at the source at face value, and it doesn't
expand macros as a C compiler would.  So this:

  Py_LOCAL_INLINE(void) stackdepth_push(basicblock ***sp, basicblock *b, int depth)

looks to its naïve lexical analysis very much like a K&R definition of
a function and declaration of its arguments:

  Py_LOCAL_INLINE(foo) int foo(bar)

> Seems like a bug to me, but it's not obvious if there is a trivial
> fix.

Patches are welcome, if someone has an idea for how to fix that.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Mon, 09 Dec 2019 11:00:02 GMT) Full text and rfc822 format available.

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

From: Francesco Potortì <pot <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Skip Montanaro <skip.montanaro <at> gmail.com>, 38511 <at> debbugs.gnu.org
Subject: Re: bug#38511: etags seems to be confused by macros
Date: Mon, 09 Dec 2019 11:59:06 +0100
>> From: Skip Montanaro <skip.montanaro <at> gmail.com>
>> Date: Fri, 6 Dec 2019 14:20:14 -0600
>> 
>> I use speedbar in Emacs, which relies on etags to generate tag files.
>> The Python source defines a macro named Py_LOCAL_INLINE, which is used
>> to select the appropriate spelling of "static inline":
>> 
>> #if defined(_MSC_VER)
>> ...
>> #  define Py_LOCAL_INLINE(type) static __inline type __fastcall
>> #else
>> ...
>> #  define Py_LOCAL_INLINE(type) static inline type
>> #endif
>> 
>> It's used like so:
>> 
>> Py_LOCAL_INLINE(void)
>> stackdepth_push(basicblock ***sp, basicblock *b, int depth)
>> {
>>     assert(b->b_startdepth < 0 || b->b_startdepth == depth);
>>     if (b->b_startdepth < depth && b->b_startdepth < 100) {
>>         assert(b->b_startdepth < 0);
>>         b->b_startdepth = depth;
>>         *(*sp)++ = b;
>>     }
>> }
>> 
>> It all works well. Etags though, thinks the file contains a function
>> named "Py_LOCAL_INLINE" and completely misses the actual function,
>> "stackdepth_push".

Eli Zaretskii:
>Etags works by looking at the source at face value, and it doesn't
>expand macros as a C compiler would.  So this:
>
>  Py_LOCAL_INLINE(void) stackdepth_push(basicblock ***sp, basicblock *b, int depth)
>
>looks to its naïve lexical analysis very much like a K&R definition of
>a function and declaration of its arguments:
>
>  Py_LOCAL_INLINE(foo) int foo(bar)
>
>> Seems like a bug to me, but it's not obvious if there is a trivial
>> fix.
>
>Patches are welcome, if someone has an idea for how to fix that.

Unless some C code wizard steps up and contradicts me, I'd say that it
is in principle impossible for Etags to detect such macros.  This is a
work for the --regex feature of Etags, which is thought just for this
sort of situations.

The Etags man page explains it with examples, as does the info page.

--
fp




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Mon, 09 Dec 2019 12:41:01 GMT) Full text and rfc822 format available.

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

From: Skip Montanaro <skip.montanaro <at> gmail.com>
To: Francesco Potortì <pot <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38511 <at> debbugs.gnu.org
Subject: Re: bug#38511: etags seems to be confused by macros
Date: Mon, 9 Dec 2019 06:39:33 -0600
> Eli Zaretskii:

> Etags works by looking at the source at face value, and it doesn't
> expand macros as a C compiler would.  So this:
>
>  Py_LOCAL_INLINE(void) stackdepth_push(basicblock ***sp, basicblock *b, int depth)
>
> looks to its naïve lexical analysis very much like a K&R definition of
> a function and declaration of its arguments:
...
> Patches are welcome, if someone has an idea for how to fix that.

> Franceso:

> Unless some C code wizard steps up and contradicts me, I'd say that it
> is in principle impossible for Etags to detect such macros.  This is a
> work for the --regex feature of Etags, which is thought just for this
> sort of situations.
>
> The Etags man page explains it with examples, as does the info page.

I read the documentation and didn't understand how the regex feature
would help. It seems to be useful to identify other constructs which
you'd like tagged (such as the DEFVAR macro in the Emacs source), not
transform the source in some way. Put another way, I need a
"find/replace" sort of feature, not just a "find" feature.

FWIW, here's the simple shell script I came up with:

#!/bin/bash

# etags gets confused by Python's use of the Py_LOCAL and Py_LOCAL_INLINE
# macros to select compiler-dependent static storage syntax. This script is
# a stand-in for etags which performs the macro expansion manually, then
# pipes the result to etags. $@ are the args to pass to etags.

sed -E -e 's/Py_LOCAL_INLINE *\(([^(]+)\)/static inline \1/' \
    -e 's/Py_LOCAL *\(([^(]+)\)/static \1/' \
    | etags "$@"

I set speedbar-fetch-etags-command to that script. Seems to work well
enough for my needs. It clearly isn't a general solution though. I
suppose I could try to run the source through cpp, though I don't know
if etags is smart enough to use the "# <line> <file>" output of cpp.

I'll take a look at etags.c, but don't hold your breath waiting for a
miracle. :-)

Skip




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Mon, 09 Dec 2019 13:31:01 GMT) Full text and rfc822 format available.

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

From: Francesco Potortì <pot <at> gnu.org>
To: Skip Montanaro <skip.montanaro <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38511 <at> debbugs.gnu.org
Subject: Re: bug#38511: etags seems to be confused by macros
Date: Mon, 09 Dec 2019 14:30:10 +0100
>I read the documentation and didn't understand how the regex feature
>would help. It seems to be useful to identify other constructs which
>you'd like tagged (such as the DEFVAR macro in the Emacs source), not
>transform the source in some way. Put another way, I need a
>"find/replace" sort of feature, not just a "find" feature.

Try this one, and let us know if it satisfies your needs:

etags --regex='/Py_LOCAL_INLINE[ \t]*(.*)\n[^(]+(\([^)]+\)/m'

It assumes that Py_LOCAL_INLINE and its arguments all stay on a single
line, but it can be easily changed to waive this assumption.

-- 
Francesco Potortì (ricercatore)        Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR          Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa         Skype:  wnlabisti
(gate 20, 1st floor, room C71)         Web:    http://fly.isti.cnr.it




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38511; Package emacs. (Tue, 31 Aug 2021 02:06:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: Skip Montanaro <skip.montanaro <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 38511 <at> debbugs.gnu.org
Subject: Re: bug#38511: etags seems to be confused by macros
Date: Tue, 31 Aug 2021 04:05:37 +0200
Francesco Potortì <pot <at> gnu.org> writes:

> Unless some C code wizard steps up and contradicts me, I'd say that it
> is in principle impossible for Etags to detect such macros.

Yeah, so I think this is a bit out of the remit for etags.  So I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 38511 <at> debbugs.gnu.org and Skip Montanaro <skip.montanaro <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 31 Aug 2021 02:06:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 28 Sep 2021 11:24:06 GMT) Full text and rfc822 format available.

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

Previous Next


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