Description
Per discussion of #283, 3c currently exits gracefully if it sees multiple definitions of the same symbol (that issue suggests that the way to fail should be changed to work with clang3c). But it would actually be OK to support multiple definitions as long as they share the same constraint variables. Doing so should be a simple extension of what's currently done.
Consider this program:
int main(int argc, char **argv);
int main(int argc, char **argv) {
...
}
The declaration and definition of main are "merged" so that both share the same constraint variable. In particular, ProgramInfo::ExternFunctionFVCons will map main to an FVConstraint, call it p, and ProgramInfo::Variables will map both the declaration and definition of main (which have two different PersistentSourceLocations) to p.
Merging of declaration and definition constraints is currently only allowed when we have a definition and one or more declarations; if 3c sees two definitions then it exits with failure. But it seems to me that it would be perfectly fine to allow multiple definitions. In particular, suppose we had
int main(int argc, char **argv) {
...
}
defined in two different files a.c and b.c and we analyzed them together. What we want to happen is that the bodies of these two definitions' bodies should be analyzed with the same FVConstraint, i.e., p in our example above.
Multiple definitions should only be allowed in this way if they have the same type. If they do not, then the merge is not OK (just as it is not OK now, when trying to merge incompatible declarations).
This is a special case of #341.
Note: It might be that we want treat main specially, since its type is often abused. For example, we might see void main() or int main() or void main(int argc, char **argv) etc. Even though these types are not normally compatible I think we should change the mergeDeclaration code to allow them (which we can always solve to the well known prototype for main).