emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

maintaining etags


From: Francesco Potortì
Subject: maintaining etags
Date: Mon, 11 May 2015 17:37:22 +0200

>> > C is a hard language to parse with ad-hoc parsers.  If you know of a
>> > better tool that doesn't get confused by the source at that point of
>> > lisp.h (did you look at it?), name it.
>> 
>> GNU Global doesn't, at least not in this example:
>> 
>> ~/v/e/src> global -x Lisp_Object
>> Lisp_Object 567 lisp.h typedef struct { EMACS_INT i; } Lisp_Object;
>> Lisp_Object 577 lisp.h typedef EMACS_INT Lisp_Object;
>
>With the patch below, neither will etags.
>
>Francesco, do you see any problems with it?

Eli, I see that you move around Etags's state machinery without problems.

In the last many years, my main job has gradually moved away from
programming, so every time I try to do something with Etags' sources I
must invest some significant amount of time even to just download the
latest sources and look at it.  To be true, I am not even sure what sort
of code revision backend Emacs developers currently use...

Long story short, my role as Etags maintainer is, to be mild, obsolete,
and maybe someone else (you? Stefan?) should take over :)

Anyway, when I used to patch Etags, I always run a regression test,
then updated the regression test with the case the patch was meant to
address.  The tests that I used can be found in the tree at
<http://fly.isti.cnr.it/pub/software/unix/etags-regression-test.tar>,
together with some garbage.  The tests are invoked from the Makefile as
the default target.  If, as I hope, someone will care to install the
regression tests in the Emacs tree I can assist with answers to
questions. 

The patch you propose is the sort of patch that should be run against a
regression test, as it is not always obvious what will happen in the
general case.

>--- lib-src/etags.c~0  2015-03-29 08:32:03 +0300
>+++ lib-src/etags.c    2015-05-10 12:15:23 +0300
>@@ -2862,7 +2862,10 @@ consider_token (char *str, int len, int
>      case st_none:
>        if (constantypedefs
>          && structdef == snone
>-         && structtype == st_C_enum && bracelev > structbracelev)
>+         && structtype == st_C_enum && bracelev > structbracelev
>+         /* Don't tag tokens in expressions that assign values to enum
>+            constants.  */
>+         && fvdef != vignore)
>        return true;           /* enum constant */
>        switch (fvdef)
>        {
>@@ -3176,7 +3179,19 @@ C_entries (int c_ext, FILE *inf)
>                     cpptoken = false;
>                 }
>             if (cpptoken)
>-              definedef = dsharpseen;
>+              {
>+                definedef = dsharpseen;
>+                /* This is needed for tagging enum values: when there are
>+                   preprocessor conditionals inside the enum, we need to
>+                   reset the value of fvdef so that the next enum value is
>+                   tagged even though the one before it did not end in a
>+                   comma.  */
>+                if (fvdef == vignore && instruct && parlev == 0)
>+                  {
>+                    if (strneq (cp, "#if", 3) || strneq (cp, "#el", 3))
>+                      fvdef = fvnone;
>+                  }
>+              }
>           } /* if (definedef == dnone) */
>         continue;
>       case '[':
>@@ -3507,7 +3522,10 @@ C_entries (int c_ext, FILE *inf)
>           case fstartlist:
>           case finlist:
>           case fignore:
>+            break;
>           case vignore:
>+            if (instruct && parlev == 0)
>+              fvdef = fvnone;
>             break;
>           case fdefunname:
>             fvdef = fignore;
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]