summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate/qualified-names-diag.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Lit Test] Updated 34 Lit tests to be C++11 compatible.Charles Li2015-11-171-1/+6
| | | | | | | Added expected diagnostics new to C++11. Expanded RUN line to: default, C++98/03 and C++11. llvm-svn: 253371
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - 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). llvm-svn: 91446
* When overload resolution fails for an overloaded operator, show theDouglas Gregor2009-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 83175
* Avoid using the built-in type checker for assignment in C++ when classes are ↵Sebastian Redl2009-05-211-1/+1
| | | | | | involved. Patch by Vyacheslav Kononenko. llvm-svn: 72212
* Give Type::getDesugaredType a "for-display" mode that can apply moreDouglas Gregor2009-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | heuristics to determine when it's useful to desugar a type for display to the user. Introduce two C++-specific heuristics: - For a qualified type (like "foo::bar"), only produce a new desugred type if desugaring the qualified type ("bar", in this case) produces something interesting. For example, if "foo::bar" refers to a class named "bar", don't desugar. However, if "foo::bar" refers to a typedef of something else, desugar to that something else. This gives some useful desugaring such as "foo::bar (aka 'int')". - Don't desugar class template specialization types like "basic_string<char>" down to their underlying "class basic_string<char, char_traits<char>, allocator<char>>, etc."; it's better just to leave such types alone. Update diagnostics.html with some discussion and examples of type preservation in C++, showing qualified names and class template specialization types. llvm-svn: 68207
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Print the context of tag types as part of pretty-printing, e.g.,Douglas Gregor2009-03-191-1/+1
| | | | | | struct N::M::foo llvm-svn: 67284
* Extend the use of QualifiedNameType to the creation of class templateDouglas Gregor2009-03-191-0/+16
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. llvm-svn: 67268
OpenPOWER on IntegriCloud