Cxx/CPreProcessor: fix-bug, both branch should visited, now don't processs

[jlugjb]

struct sType { union { #ifdef Condition struct { int usMember1; }; #else struct { int usMember2;
}; #endif }; }; before change: sType D:\CodeStyle\refactorctags\ifdef2.c 1;" struct file: __anonf8dce96c010a D:\CodeStyle\refactorctags\ifdef2.c 4;" union struct:sType file: __anonf8dce96c0208 D:\CodeStyle\refactorctags\ifdef2.c 7;" struct union:sType::__anonf8dce96c010a file: usMember1 D:\CodeStyle\refactorctags\ifdef2.c 8;" member struct:sType::__anonf8dce96c010a::__anonf8dce96c0208 typeref:typename:int file:

change after: sType D:\CodeStyle\refactorctags\ifdef2.c 1;" struct file: __anonf8dce96c010a D:\CodeStyle\refactorctags\ifdef2.c 4;" union struct:sType file: __anonf8dce96c0208 D:\CodeStyle\refactorctags\ifdef2.c 7;" struct union:sType::__anonf8dce96c010a file: usMember1 D:\CodeStyle\refactorctags\ifdef2.c 8;" member struct:sType::__anonf8dce96c010a::__anonf8dce96c0208 typeref:typename:int file: __anonf8dce96c0308 D:\CodeStyle\refactorctags\ifdef2.c 12;" struct union:sType::__anonf8dce96c010a file: usMember2 D:\CodeStyle\refactorctags\ifdef2.c 13;" member struct:sType::__anonf8dce96c010a::__anonf8dce96c0308 typeref:typename:int file:

[coveralls]

Coverage increased (+0.0009%) to 84.894% when pulling 724ab6624cf03ed3007b330e3878a1611497313c on jlugjb:patch-1 into befcb888004b9a02198b101d011feb169aba0b0e on universal-ctags:master.

[masatake]

@jlugjb, thank you.

Parsing only the first branch is expected behavior as ctags(1) man says:

       In  general,  ctags tries to be smart about conditional preprocessor directives. If a preprocessor conditional is encountered within a state‐
       ment which defines a tag, ctags follows only the first branch of that conditional (except in the special case of "#if 0", in  which  case  it
       follows  only  the last branch). 

@pragmaware, am I wrong?

[b4n]

Visiting conditional branches is tricky, because it can easily lead to invalid code:

struct sType {
  union {
    struct {
#ifdef Condition
      int usMember1;
    } uMember1;
#else
      int usMember2;
    } uMember2;
#endif
    int uMember3;
  };
};

taking both branches leads to unbalanced braces. And although it looks far fetched, it's actually more commonly found in the wold than you would hope to think. I don't know if the old C parser here did this, but some versions of it tried the various possible branching and dropped branches leading to unbalanced braces, which is a tricky workaround that sometimes works.

In theory I agree with the report, because as a TOC generator CTags should see both possibilities, but as said it's not that simple.

[masatake]

I have taken time for thinking about this. In some cases, this is useful.

I wonder how about introducing --param-CPreProcessor:visitAllBranches=yes option.