Re: Help etags parse lisp.j

[Eli Zaretskii]

> From: Andreas Schwab <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Mon, 21 Mar 2016 11:58:14 +0100
> 
> Paul Eggert <address@hidden> writes:
> 
> > Eli Zaretskii wrote:
> >>> >Can't etags reset its parser state after a toplevel semicolon?
> >> No, evidently because it wants to support K&R function definition:
> >>
> >>    void foo () int arg; { bar = arg; }
> >
> > OK, how about if it resets its state when it sees a toplevel semicolon not
> > immediately followed by "{"?
> 
> void foo (a, b) int a; int b; {}

Right.

To expand on that, a K&R function definition generally looks like
this:

  TYPE0 foo (arg1, arg2, arg3, ..., argN)
    TYPE1 arg1;
    TYPE2 arg2;
    TYPE3 arg3;
    ...
    TYPEN argN;
  {
    body...
  }

Compare this with what we have in lisp.h:

  extern Lisp_Object make_formatted_string (char *, const char *, ...)
    ATTRIBUTE_FORMAT_PRINTF (2, 3);
  extern Lisp_Object make_unibyte_string (const char *, ptrdiff_t);
  SOMETHING;
  SOMETHING-ELSE;
  ...
  INLINE Lisp_Object
  build_unibyte_string (const char *str)
  {
    return make_unibyte_string (str, strlen (str));
  }

A tool that doesn't really parse C will have hard time discerning
between these two.  In particular, by the time etags finds a top-level
semicolon not followed by a "{", it's too late, because the first
inline function (in this case, build_unibyte_string) was already
missed.

Hmm... can we use the fact that in a K&R definition, the last token
before the opening brace "{" of the body is always a semicolon?  So if
there's no semi-colon there, then it's a function that needs to be
tagged?  (Of course, the semicolon could be hidden behind some clever
macro, but I think we don't need to cater to such uses.)