Diagnose typedef names for linkage purposes that would change

a previously-computed linkage as an unsupportable error condition.

Per discussion on cfe-commits, this appears to be a
difficult-to-resolve flaw in our implementation approach;
we may pursue this as a language defect, but for now it's
better to diagnose it as unsupported than to produce
inconsistent results (or assertions).  Anything that we can
do to limit how often this diagnostic fires, such as the
changes in r200380, is probably for the best, though.

llvm-svn: 200438

1 files changed, 7 insertions, 0 deletions

diff --git a/clang/test/SemaCXX/anonymous-struct.cpp b/clang/test/SemaCXX/anonymous-struct.cpp
index 8a61041463b..1b5dc13cea0 100644
--- a/clang/test/SemaCXX/anonymous-struct.cpp
+++ b/clang/test/SemaCXX/anonymous-struct.cpp
@@ -14,3 +14,10 @@ struct E {
   static struct {
   };
 };
+
+template <class T> void foo(T);
+typedef struct { // expected-note {{use a tag name here to establish linkage prior to definition}} expected-note {{declared here}}
+  void test() {
+    foo(this); // expected-warning {{template argument uses unnamed type}}
+  }
+} A; // expected-error {{unsupported: typedef changes linkage of anonymous type, but linkage was already computed}}