Incompatible functions in declarative region not being checked for overload compatibility

[Quuxplusone]

Bugzilla Link	PR7084
Status	REOPENED
Importance	P normal
Reported by	Johannes Schaub (schaub.johannes@googlemail.com)
Reported on	2010-05-07 05:34:05 -0700
Last modified on	2012-06-27 18:11:24 -0700
Version	trunk
Hardware	PC Linux
CC	dgregor@apple.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

I think clang should diagnose the following:

struct string { };
void f() { string g(); g(); }
void g() { } // diagnostic expected here
int main() { f(); }

Currently it generates code that segfaults at runtime for me.

[Quuxplusone]

Assuming the code example is C++, clang 3.1 will give a vexing-parse warning by
default while producing a binary that runs without any problems:

$ cat tmp.cc
struct string { };
void f() { string g(); g(); }
void g() { } // diagnostic expected here
int main() { f(); }

$ clang++ -o tmp tmp.cc ; echo "clang++ exited with a status of $?"
tmp.cc:2:20: warning: empty parentheses interpreted as a function declaration [-
Wvexing-parse]
void f() { string g(); g(); }
                   ^~
tmp.cc:2:20: note: remove parentheses to declare a variable
void f() { string g(); g(); }
                   ^~
1 warning generated.
clang++ exited with a status of 0
$ ./tmp ; echo "./tmp exited with a status of $?"
./tmp exited with a status of 0

And for completeness, treating the example as C code yields a pair of errors:
$ clang -o tmp -x c tmp.cc
tmp.cc:2:12: error: must use 'struct' tag to refer to type 'string'
void f() { string g(); g(); }
           ^
           struct
tmp.cc:3:6: error: conflicting types for 'g'
void g() { } // diagnostic expected here
     ^
tmp.cc:2:19: note: previous declaration is here
void f() { string g(); g(); }
                  ^
2 errors generated.

[Quuxplusone]

That's still not the desired behavior. We have two declarations of ::g(), with different return types. I've not checked whether this is ill-formed, but I think we should at least warn on this.

The segfault at runtime is still present if you use std::string instead of string.