clang-1/test/SemaTemplate/qualified-names-diag.cpp

// RUN: %clang_cc1 -fsyntax-only -verify %s

namespace std {
  template<typename T> class vector { }; // expected-note{{candidate}}
}

typedef int INT;
typedef float Real;

void test() {
  using namespace std;

  std::vector<INT> v1;
  vector<Real> v2;
  v1 = v2; // expected-error{{no viable overloaded '='}}
}
Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8 2009-12-15 23:14:24 +03:00			`// RUN: %clang_cc1 -fsyntax-only -verify %s`
Extend the use of QualifiedNameType to the creation of class template specialization names. This way, we keep track of sugared types like std::vector<Real> I believe we are now using QualifiedNameTypes everywhere we can. Next step: QualifiedDeclRefExprs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67268 91177308-0d34-0410-b5e6-96231b3b80d8 2009-03-19 03:39:20 +03:00
			`namespace std {`
When overload resolution fails for an overloaded operator, show the overload candidates (but not the built-in ones). We still rely on the underlying built-in semantic analysis to produce the initial diagnostic, then print the candidates following that diagnostic. One side advantage of this approach is that we can perform more validation of C++'s operator overloading with built-in candidates vs. the semantic analysis for those built-in operators: when there are no viable candidates, we know to expect an error from the built-in operator handling code. Otherwise, we are not modeling the built-in semantics properly within operator overloading. This is checked as: assert(Result.isInvalid() && "C++ binary operator overloading is missing candidates!"); if (Result.isInvalid()) PrintOverloadCandidates(CandidateSet, /OnlyViable=/false); The assert() catches cases where we're wrong in a +Asserts build. The "if" makes sure that, if this happens in a production clang (-Asserts), we still build the proper built-in operator and continue on our merry way. This is effectively what happened before this change, but we've added the assert() to catch more flies. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83175 91177308-0d34-0410-b5e6-96231b3b80d8 2009-10-01 01:46:01 +04:00			`template<typename T> class vector { }; // expected-note{{candidate}}`
Extend the use of QualifiedNameType to the creation of class template specialization names. This way, we keep track of sugared types like std::vector<Real> I believe we are now using QualifiedNameTypes everywhere we can. Next step: QualifiedDeclRefExprs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67268 91177308-0d34-0410-b5e6-96231b3b80d8 2009-03-19 03:39:20 +03:00			`}`

			`typedef int INT;`
			`typedef float Real;`

			`void test() {`
			`using namespace std;`

			`std::vector<INT> v1;`
			`vector<Real> v2;`
Avoid using the built-in type checker for assignment in C++ when classes are involved. Patch by Vyacheslav Kononenko. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72212 91177308-0d34-0410-b5e6-96231b3b80d8 2009-05-21 15:50:50 +04:00			`v1 = v2; // expected-error{{no viable overloaded '='}}`
Extend the use of QualifiedNameType to the creation of class template specialization names. This way, we keep track of sugared types like std::vector<Real> I believe we are now using QualifiedNameTypes everywhere we can. Next step: QualifiedDeclRefExprs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67268 91177308-0d34-0410-b5e6-96231b3b80d8 2009-03-19 03:39:20 +03:00			`}`