bug#38511: etags seems to be confused by macros

[Francesco Potortì]

>> From: Skip Montanaro <skip.montanaro@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