Re: [Ctags] preprocessor conditionals

[Darren H. <da...@hi...>]

Mark Frazer wrote:

> Has anyone come up with a good way to have Ctags preprocess some of the
> preprocessor conditionals when generating tags?
>
> I'm using ctags on the linux kernel and would like to have ctags apply
> the #if VERSION > whatever logic when the tags are generated.

Ctags already does parse preprocessor conditionals. However, it
follows all paths of a conditional unless the conditional occurs in
the middle of a statement. This approach is taken because ctags' job
is to locate definitions, not compile. However, your suggestion
probably would not accomplish what you think it would.

Consider this example:

#if VERSION > 3

int foo (int b)
{
    /* implementation 1 */
}

#else

int foo (int b)
{
    /* implementation 2 */
}

#end

I presume that you are wanting your editor to take you to the first
definition for foo() if VERSION > 3, or to the second if VERSION <=
3. However, even if ctags followed only one path of the conditional,
you would not get the behavior you expect. This is because ctags
records a search expression for finding foo() into the tag file:

    /^int foo (int b)$/

This pattern will find the first definition when the editor uses it
to locate the tag. The only way to overcome this behavior of
locating the definition is to use the -n option to force line
numbers to be recorded. Therefore, *if* ctags could be instructed to
follow only one path, *and* if you used -n, then you could get what
you wanted.

However, allowing ctags to follow only one path of a conditional
would have certain consequences:

1.  Ctags would have to support full expression evaluation
    (e.g. #if A + 3 > B).

2.  Ctags does not follow #include directives -- it parses only the
    files specified on the command line. This means that if an
    included file defined the value upon with a preprocessor
    conditional depended, it would not be correctly evaluated.

I believe that it is too much work to do for a small benefit which
would only be right some of the time.

-- 
Darren Hiebert <da...@hi...>
http://darren.hiebert.com