Merge rewrites to different `#if` branches of same header from different translation units

[john-h-kastner]

When a function prototype in a header file occurs in both branches of an #ifdef conditional, it is only rewritten to the correct checked type in one branch even if both branches are expanded by at different times when the header is included in different files.

In the example below, only the #else branch is rewritten. Since a.c takes the #if branch, it sees an unchecked prototype, causing a compiler error.

This pattern is used by yacr2 in the ptrdist benchmark.

---

Example:

a.c:

#define FOO
#include "test.h"

int *fn(void) {
  return 0;
}

void testa() {
  int *a = fn();
}

b.c:

include "test.h"

void testb() {
  int *a = fn();
}

test.h:

#ifdef FOO
int *fn(void);
#else
int *fn(void);
#endif

---

Conversion with 3c --output-postfix=checked a.c b.c test.h

a.checked.c:

#define FOO
#include "test.h"

_Ptr<int> fn(void) {
  return 0;
}

void testa() {
  _Ptr<int> a = fn();
}

b.checked.c:

include "test.h"

void testb() {
  _Ptr<int> a = fn();
}

test.checked.h:

#ifdef FOO
int *fn(void);
#else
_Ptr<int> fn(void);
#endif

[john-h-kastner]

I looked into this some more since it's blocking the yacr2 program in the ptrdist benchmarks. It turns out that both declarations of fn are being rewritten, but one is rewritten as part of the a.c translation unit while the other is rewritten in the b.c translation unit. The a.c TU is processed first, and test.h is initially rewritten with the first declaration of fn checked. To see this, set a breakpoints after RewriteConsumer::HandleTranslationUnit and cat test.h before continuing execution.

#ifdef FOO
_Ptr<int> fn(void);
#else
int *fn(void);
#endif

If we let execution continue, test.h is rewritten again for the b.c translation unit (clobbering the output from a.c) . This time the second declaration is checked as shown in the original comment on this issue. Put together, the rewritings are correct, but on their own neither is complete.

Somehow we need rewrite both declaration in one pass. This might be somewhat complicated since each translation unit can only access its in scopeFunctionDeclaration object. Perhaps Kyle's open pull request will allow us to rewrite files across all translation units in one pass.

[mwhicks1]

Or, can we write out all the different copies of the .h file separately, and then call the equivalent of git-merge to merge them together? I don't know if that merge algorithm is available independent of git, but I wouldn't be surprised if it is.

[mattmccutchen-cci]

I don't know if that merge algorithm is available independent of git, but I wouldn't be surprised if it is.

Don't worry, I've got this. 😄

[john-h-kastner]

With mwhicks1/3c-actions#19 merged, this issue has been worked around and is no longer blocking our benchmarks.

[john-h-kastner]

See the example in #661 for another demonstration of this issue. The sample file is included twice in the compilation database, so 3C processes it twice, and then prints it to stdout twice.

[mattmccutchen-cci]

See the example in #661 for another demonstration of this issue. The sample file is included twice in the compilation database, so 3C processes it twice, and then prints it to stdout twice.

That's hilarious. This GitHub issue as currently stated is just about the incomplete #if rewriting, not the broader design weakness of rewriting each translation unit separately; we could broaden this issue or file a separate one. In any case, I don't know when or if we'll improve the design, so I think it may make sense to go ahead and fix the duplicate-stdout bug. I prototyped a fix; I based it on #666 since #666 has a test file to which verification of the stdout was easy to add. Do you want to roll this into #666, or shall I submit it as a separate PR later?