PR48339: Improve diagnostics for invalid dependent unqualified function calls.Fix bogus diagnostics that would get confused and think a "no viablefuctions" case was an "undeclared identifiers" cas
PR48339: Improve diagnostics for invalid dependent unqualified function calls.Fix bogus diagnostics that would get confused and think a "no viablefuctions" case was an "undeclared identifiers" case, resulting in anincorrect diagnostic preceding the correct one. Use overload resolutionto determine which function we should select when we can find callcandidates from a dependent base class. Make the diagnostics for a callthat could call a function from a dependent base class more specific,and use a different diagnostic message for the case where the calltarget is instead declared later in the same class. Plus some minordiagnostic wording improvements.
show more ...
Fix parsing of enum-base to follow C++11 rules.Previously we implemented non-standard disambiguation rules todistinguish an enum-base from a bit-field but otherwise treated a :after an elaborated
Fix parsing of enum-base to follow C++11 rules.Previously we implemented non-standard disambiguation rules todistinguish an enum-base from a bit-field but otherwise treated a :after an elaborated-enum-specifier as introducing an enum-base. Thatmisparses various examples (anywhere an elaborated-type-specifier canappear followed by a colon, such as within a ternary operator or_Generic).We now implement the C++11 rules, with the old cases accepted asextensions where that seemed reasonable. These amount to: * an enum-base must always be accompanied by an enum definition (except in a standalone declaration of the form 'enum E : T;') * in a member-declaration, 'enum E :' always introduces an enum-base, never a bit-field * in a type-specifier (or similar context), 'enum E :' is not permitted; the colon means whatever else it would mean in that context.Fixed underlying types for enums are also permitted in Objective-C andunder MS extensions, plus as a language extension in all other modes.The behavior in ObjC and MS extensions modes is unchanged (but thebit-field disambiguation is a bit better); remaining language modesfollow the C++11 rules.Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++core issues 1514 and 1966.
Update error message text.Previously if an enumeration was used in a nested name specifier in pre-C++11language dialect, error message was 'XXX is not a class, namespace, or scopedenumeration'. T
Update error message text.Previously if an enumeration was used in a nested name specifier in pre-C++11language dialect, error message was 'XXX is not a class, namespace, or scopedenumeration'. This patch removes the word 'scoped' as in C++11 any enumerationmay be used in this context.llvm-svn: 226410
PR21437, final part of DR1330: delay-parsing of exception-specifications. Thisis a re-commit of Doug's r154844 (modernized and updated to fit into currentClang).llvm-svn: 221918
Don't allow 'this' within typedefs within classes that otherwise look like theymight be member function declarations. Patch by Harald van Dijk!llvm-svn: 199512
PR16243: Use CXXThisOverride during template instantiation, and fix up theplaces which weren't setting it up properly. This allows us to get the rightcv-qualifiers for 'this' when it appears outsid
PR16243: Use CXXThisOverride during template instantiation, and fix up theplaces which weren't setting it up properly. This allows us to get the rightcv-qualifiers for 'this' when it appears outside a method body in a classtemplate.llvm-svn: 183483
<rdar://problem/13473493> Handle 'this->' insertion recovery within trailing return types.llvm-svn: 178081
PR15290: 'this' is not permitted in the declaration of a friend function,therefore references to members should not be transformed into implicit uses of'this'. Patch by Ismail Pazarbasi!llvm-svn:
PR15290: 'this' is not permitted in the declaration of a friend function,therefore references to members should not be transformed into implicit uses of'this'. Patch by Ismail Pazarbasi!llvm-svn: 177134
Fix directive parsing in VerifyDiagnosticConsumer so that it ensures that "expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" direc
Fix directive parsing in VerifyDiagnosticConsumer so that it ensures that "expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" directive. A very few test-cases had to be amended to adhere to the new rule.Patch reviewed by David Blaikie.llvm-svn: 166279
Disable our non-standard delayed parsing of exception specifications. Delayingthe parsing of such things appears to be a conforming extension, but it breakslibstdc++4.7's std::pair.llvm-svn: 1559
Disable our non-standard delayed parsing of exception specifications. Delayingthe parsing of such things appears to be a conforming extension, but it breakslibstdc++4.7's std::pair.llvm-svn: 155975
Implement the last part of C++ [class.mem]p2, delaying the parsing ofexception specifications on member functions until after the closing'}' for the containing class. This allows, for example, a me
Implement the last part of C++ [class.mem]p2, delaying the parsing ofexception specifications on member functions until after the closing'}' for the containing class. This allows, for example, a memberfunction to throw an instance of its own class. Fixes PR12564 and afairly embarassing oversight in our C++98/03 support.llvm-svn: 154844
Implement C++11 [expr.prim.general]p3, which permits the use of 'this'in the declaration of a non-static member function after the(optional) cv-qualifier-seq, which in practice means in the excepti
Implement C++11 [expr.prim.general]p3, which permits the use of 'this'in the declaration of a non-static member function after the(optional) cv-qualifier-seq, which in practice means in the exceptionspecification and late-specified return type. The new scheme here used to manage 'this' outside of a member functionscope is more general than the Scope-based mechanism previously usedfor non-static data member initializers and late-parsesd attributes,because it can also handle the cv-qualifiers on the memberfunction. Note, however, that a separate pass is required for staticmember functions to determine whether 'this' was used, because wemight not know that we have a static function until after declarationmatching.Finally, this introduces name mangling for 'this' and for the implicit'this', which is intended to match GCC's mangling. Independentverification for the new mangling test case would be appreciated.Fixes PR10036 and PR12450.llvm-svn: 154799
Improve diagnostics for invalid use of non-static members / this:* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted the former by 28-2 in our diagnostics.* Fix the "use
Improve diagnostics for invalid use of non-static members / this:* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted the former by 28-2 in our diagnostics.* Fix the "use of member in static member function" diagnostic to correctly detect this situation inside a block or lambda.* Produce a more specific "invalid use of non-static member" diagnostic for the case where a nested class member refers to a member of a lexically-surrounding class.llvm-svn: 154073
PR11956: C++11's special exception for accessing non-static data members fromunevaluated operands applies within member functions, too.llvm-svn: 151443
In the conflict between C++11 [expr.prim.general]p4, which declaresthat 'this' can be used in the brace-or-equal-initializer of anon-static data member, and C++11 [expr.prim.lambda]p9, which sayst
In the conflict between C++11 [expr.prim.general]p4, which declaresthat 'this' can be used in the brace-or-equal-initializer of anon-static data member, and C++11 [expr.prim.lambda]p9, which saysthat lambda expressions not in block scope can have no captures, sidefully with C++11 [expr.prim.general]p4 by allowing 'this' to becaptured within these initializers. This seems to be the intent ofnon-static data member initializers.llvm-svn: 151101
Remove PotentiallyPotentiallyEvaluated, and replace it with a much simpler and less error-prone way of handling the relevant cases. Towards marking of whether a declaration is used more accurately.
Remove PotentiallyPotentiallyEvaluated, and replace it with a much simpler and less error-prone way of handling the relevant cases. Towards marking of whether a declaration is used more accurately.llvm-svn: 148522
Make PotentiallyPotentiallyEvaluated contexts work correctly when referencing a class field from outside an instance method.llvm-svn: 148376
Unlike in C++03, a constant-expression is not an unevaluated operand in C++11.Split out a new ExpressionEvaluationContext flag for this case, and don't treatit as unevaluated in C++11. This fixes s
Unlike in C++03, a constant-expression is not an unevaluated operand in C++11.Split out a new ExpressionEvaluationContext flag for this case, and don't treatit as unevaluated in C++11. This fixes some crash-on-invalids where we wouldallow references to class members in potentially-evaluated constant expressionsin static member functions, and also fixes half of PR10177.The fix to PR10177 exposed a case where template instantiation failed to providea source location for a diagnostic, so TreeTransform has been tweaked to supplysource locations when transforming a type. The source location is still not verygood, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc toimprove it further.Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation forstatic data members of class templates which are used in constant expressions.This fixes a link-time problem, but we still incorrectly treat the member asnon-constant. The rest of the fix for that issue is blocked on PCH support forearly-instantiated static data members, which will be added in a subsequentpatch.llvm-svn: 146955
Disallow decltype in qualified declarator-ids.llvm-svn: 146480
Support decltype in nested-name-specifiers.llvm-svn: 145785
Move tests to the appropriate directory to match the spec hierarchy.llvm-svn: 143906