aboutsummaryrefslogtreecommitdiff
path: root/test/SemaTemplate/instantiate-member-class.cpp
AgeCommit message (Collapse)Author
2012-08-08Implement warning for integral null pointer constants other than the literal 0.David Blaikie
This is effectively a warning for code that violates core issue 903 & thus will become standard error in the future, hopefully. It catches strange null pointers such as: '\0', 1 - 1, const int null = 0; etc... There's currently a flaw in this warning (& the warning for 'false' as a null pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0' for example). Fix to come in a future patch. Also, due to this only being a warning, not an error, it triggers quite frequently on gtest code which tests expressions for null-pointer-ness in a SFINAE context (so it wouldn't be a problem if this was an error as in an actual implementation of core issue 903). To workaround this for now, the diagnostic does not fire in unevaluated contexts. Review by Sean Silva and Richard Smith. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161501 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-07Tighten up the conditions under which we consider ourselves to beDouglas Gregor
entering the context of a nested-name-specifier. Fixes <rdar://problem/10397846>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143967 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-12Switch diagnostic text from "C++0x" over to "C++11".Douglas Gregor
We'd also like for "C++11" or "c++11" to be used for the warning groups, but without removing the old warning flags. Patches welcome; I've run out of time to work on this today. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141801 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-01Fix AST representations of alias-declarations which define tag types. Inside ↵Richard Smith
classes, the tag types need to have an associated access specifier, and inside function definitions, they need to be included in the declarations of the DeclStmt. These issues manifested as assertions during template instantiation, and also in a WIP constexpr patch. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134250 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-06We may fail to map a declaration in a template to its instantiatedDouglas Gregor
declaration because of interesting ordering dependencies while instantiating a class template or member class thereof. Complain, rather than asserting (+Asserts) or silently rejecting the code (-Asserts). Fixes the crash-on-invalid in PR8965. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127129 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-09Turn access control on by default in -cc1.John McCall
Remove -faccess-control from -cc1; add -fno-access-control. Make the driver pass -fno-access-control by default. Update a bunch of tests to be correct under access control. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100880 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-09Improve diagnostics when we fail to convert from a source type to aDouglas Gregor
destination type for initialization, assignment, parameter-passing, etc. The main issue fixed here is that we used rather confusing wording for diagnostics such as t.c:2:9: warning: initializing 'char const [2]' discards qualifiers, expected 'char *' [-pedantic] char *name = __func__; ^ ~~~~~~~~ We're not initializing a 'char const [2]', we're initializing a 'char *' with an expression of type 'char const [2]'. Similar problems existed for other diagnostics in this area, so I've normalized them all with more precise descriptive text to say what we're initializing/converting/assigning/etc. from and to. The warning for the code above is now: t.c:2:9: warning: initializing 'char *' from an expression of type 'char const [2]' discards qualifiers [-pedantic] char *name = __func__; ^ ~~~~~~~~ Fixes <rdar://problem/7447179>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100832 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-26Properly account for redeclarations when explicitly instantiating class ↵John McCall
templates. What happens here is that we actually turn the first declaration into a definition, regardless of whether it was actually originally a definition, and furthermore we do this all after we've instantiated all the declarations. This exposes a bug in my DefinitionData patch where it was only setting the DefinitionData for previous declarations, not future declarations. Fortunately, there's an iterator for that. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99657 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-10When pretty-printing tag types, only print the tag if we're in C (andJohn McCall
therefore not creating ElaboratedTypes, which are still pretty-printed with the written tag). Most of these testcase changes were done by script, so don't feel too sorry for my fingers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98149 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-13Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor
that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93322 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-15Link up member-class redeclarations during template instantiation.John McCall
This test courtesy of LLVM. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91462 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-15Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar
- 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-03-25Fix notes regarding the instantiation of member classes (and test 'em).Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67708 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-25Instantiation for member classes of class templates. Note that onlyDouglas Gregor
the declarations of member classes are instantiated when the owning class template is instantiated. The definitions of such member classes are instantiated when a complete type is required. This change also introduces the injected-class-name into a class template specialization. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67707 91177308-0d34-0410-b5e6-96231b3b80d8