Handle function declaration appearing after definition (fix #399)

[john-h-kastner]

Ensure that constrains generated due to a function's declaration are
applied to the variables generated at the definition even when
declaration appears after the definition. This is done by copying
the atoms from the definition constraint variable into the declaration
constraint variable using brainTransplant before any constraints are
added on the declaration.

[mattmccutchen-cci]

While trying to understand the code of this PR and confirm that it restores the symmetry between a declaration before and after the definition, I noticed a problem that pre-dated the PR: When we have a declaration and a definition of the same function in two different files with inconsistent parameter types, we should do the same consistency check as when we have two declarations, otherwise 3C may crash. An example:

mismatch1.c:

void foo(char *x);

mismatch2.c:

void foo(char **y) {
  // this is the body
}

Before this PR, 3c --output-postfix=scratch mismatch1.c mismatch2.c crashes, while 3c --output-postfix=scratch mismatch2.c mismatch1.c silently ignores the declaration (that's the problem this PR is intended to fix). With this PR, both cases crash. John, do you want to take this on here, or shall I file a separate issue?

I also notice that some of the existing code treats inconsistent declarations/definitions differently if one of them happens to have zero parameters (even when written explicitly as void foo(void) rather than void foo(), which is interpreted as having unspecified parameters). But I believe our decision was that if the input program is invalid, 3C just needs to not crash and its output is undefined.

[john-h-kastner]

@mattmccutchen-cci I went ahead and made the functions return void. I think the real meaning of the boolean return value was lost at some point. It's supposed to indicate success, but that hasn't been maintained by various changes to the function (including this one).

Your comments about incompatible function declaration/definitions are best handled in a separate issue. I'm not sure how exactly we want to handle it, and I feel like we might run into more questions about what should happen during constraint variable merging that could quickly expand the scope of the PR.

[mattmccutchen-cci]

Your comments about incompatible function declaration/definitions are best handled in a separate issue. I'm not sure how exactly we want to handle it, and I feel like we might run into more questions about what should happen during constraint variable merging that could quickly expand the scope of the PR.

I think the intended behavior for now is clear (just exit like with two incompatible declarations; it could get more complicated in the future if we wanted to recover gracefully and still process the definition), but I agree this could expand the scope of the PR, so I've filed #414.

All of my concerns have been addressed (thanks!), but I don't feel qualified to approve the PR as a whole.

[mwhicks1]

Looks good to me. I'm a little confused about why the "unifyIfTypedef" code has shown up, but I trust that it's OK. If it's consequential, I might have liked to see the impact of it in a new test.