it's likely to lead to a crash later on. Fixes PR12933 /
<rdar://problem/11525335>.

llvm-svn: 163838

Don't try to check override control for invalid member functions. Fixes a crash in a corner case. Patch by Olivier Goffart!

llvm-svn: 163337

Also update the tests that rely on c++98 to explicitly mention that.

llvm-svn: 162890

nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).

This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.

llvm-svn: 162159

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.

llvm-svn: 161501

accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.

Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.

llvm-svn: 160998

a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).

EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.

This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.

The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.

Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).

llvm-svn: 160847

pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.

llvm-svn: 160246

as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.

llvm-svn: 160245

being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.

llvm-svn: 160244

has a much lower default stack limit than the systems I have access to.

llvm-svn: 160240

to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.

llvm-svn: 160161

 * When substituting a reference to a non-type template parameter pack where the
   corresponding argument is a pack expansion, transform into an expression
   which contains an unexpanded parameter pack rather than into an expression
   which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
   to be inside the PackExpansionExpr, rather than outside, so the expression
   still looks like a pack expansion and can be deduced.

 * Teach MarkUsedTemplateParameters that we can deduce a reference to a template
   parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
   added during alias template substitution).

llvm-svn: 159922

llvm-svn: 159917

I'll try to increase stack size later.

llvm-svn: 159912

expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.

llvm-svn: 159909

-ftemplate-depth limit.  There are various ways to get an infinite (or merely
huge) stack of substitutions with no intervening instantiations. This is also
consistent with gcc's behavior.

llvm-svn: 159907

which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.

llvm-svn: 159895

for non-type template parameters in microsoft mode.
PR12709.

llvm-svn: 159147

when the calling site is a member function template.

Effectively reverts r111675.

llvm-svn: 159004

in microsoft mode. Fixes PR12701.

The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.

llvm-svn: 158842

initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288

feedback from Doug Gregor.

llvm-svn: 158185

That extend a range of platforms support this test case.

llvm-svn: 157247

Make delegating initializers use a similar codepath to base initializers in dependent contexts.  PR12890.

llvm-svn: 157136

accept the template argument expression as a type.

llvm-svn: 157085

Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.

Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.

llvm-svn: 156826

or template-id which can't be parsed.

llvm-svn: 156468

  candidate template ignored: substitution failed [with T = int]: no type named 'type' in 'std::enable_if<false, void>'

Instead, just say:

  candidate template ignored: disabled by 'enable_if' [with T = int]

... and point at the enable_if condition which (we assume) failed.

This is applied to all cases where the user writes 'typename enable_if<...>::type' (optionally prefixed with a nested name specifier), and 'enable_if<...>' names a complete class type which does not have a member named 'type', and this results in a candidate function being ignored in a SFINAE context. Thus it catches 'std::enable_if', 'std::__1::enable_if', 'boost::enable_if' and 'llvm::enable_if'.

llvm-svn: 156463

overload candidate, and include its message in any subsequent 'candidate not
viable due to substitution failure' note we may produce.

To keep the note small (since the 'overload resolution failed' diagnostics are
often already very verbose), the text of the SFINAE diagnostic is included as
part of the text of the note, and any notes which were attached to it are
discarded.

There happened to be spare space in OverloadCandidate into which a
PartialDiagnosticAt could be squeezed, and this patch goes to lengths to avoid
unnecessary PartialDiagnostic copies, resulting in no slowdown that I could
measure. (Removal in passing of some PartialDiagnostic copies has resulted in a
slightly smaller clang binary overall.) Even on a torture test, I was unable to
measure a memory increase of above 0.2%.

llvm-svn: 156297

llvm-svn: 155948

llvm-svn: 155670

of the template what we are going to instantiate.

Fixes various crashes of rdar://11242625 & http://llvm.org/PR11421.

llvm-svn: 155576

pretend there was no previous declaration -- that can lead us to injecting
a class template (with no access specifier) into a class scope. Instead,
just avoid the problematic checks.

llvm-svn: 155303

llvm-svn: 155271

declaration of the same name. r155187 caused us to miss this if the prior
declaration did not declare a type.

llvm-svn: 155269

up an elaborated type specifier in a friend declaration, only look for type
declarations, per [basic.lookup.elab]p2. If we know that the redeclaration
lookup for a friend class template in a dependent context finds a non-template,
don't delay the diagnostic to instantiation time.

llvm-svn: 155187

llvm-svn: 155185

llvm-svn: 155082

specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.

llvm-svn: 155076