[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38511: etags seems to be confused by macros
From: |
Eli Zaretskii |
Subject: |
bug#38511: etags seems to be confused by macros |
Date: |
Sat, 07 Dec 2019 09:14:39 +0200 |
> 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".
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.