diagnostic message are compared.  If either is a substring of the other, then
no error is given.  This gives rise to an unexpected case:

  // expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

  candidate function has different number of parameters (expected 1 but has 2)
  candidate function has different number of parameters

It will also match these other error messages:

  candidate function
  function has different number of parameters
  number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting.  Also, all the failing tests from this
change have been corrected.  Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619

llvm-svn: 146607

llvm-svn: 146580

handle non-pointer types.  This is for the extra info printed when function
types are compared.

llvm-svn: 146525

be constant expressions.

llvm-svn: 146479

The motivation here is a "clever" implementation of strncmp(), which peels the first few comparisons via chained conditional expressions which ensure that the input arrays are known at compile time to be sufficiently large.

llvm-svn: 146430

conversions in constant expressions.

llvm-svn: 146406

llvm-svn: 146395

llvm-svn: 146371

C++11 ICE rules.

llvm-svn: 146290

whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.

The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.

llvm-svn: 146289

Add notes for suppressing and (if it's a zero-arg function returning bool) fixing the function-to-bool conversion warning.

llvm-svn: 146280

Provide a separate warning for weak vtables in explicit template instantiations. There's no (current) way to fix such templates to emit strong symbols/vtables, but perhaps users want to know about the cost being incurred anyway.

llvm-svn: 146265

llvm-svn: 146174

llvm-svn: 146169

in the following code:

void test4(bool (&x)(void)) {
  while (x);
}

llvm-svn: 145918

llvm-svn: 145874

methods) to bool. E.g.

void foo() {}
if (f) { ... // <- Warns here.
}

Only applies to non-weak functions, and does not apply if the function address
is taken explicitly with the addr-of operator.

llvm-svn: 145849

Function or array lvalue conversions happens.

llvm-svn: 145782

a class is marked 'final', from Alberto Ganesh Barbati! Fixes
PR11462.

llvm-svn: 145775

inferred from return types. All the return statements have to agree about the type.
// rdar://10466373

llvm-svn: 145774

llvm-svn: 145769

explicit template specializations (which represent actual functions somebody wrote).

Along the way, refactor some other code which similarly cares about whether or
not they are looking at a template instantiation.

llvm-svn: 145547

Don't run -Wunreachable-code on template instantiations.  Different instantiations may produce different unreachable code results, and it is very difficult for us to prove that ALL instantiations of a template have specific unreachable code.  If we come up with a better solution, then we can revisit this, but this approach will at least greatly reduce the noise of this warning for code that makes use of templates.

llvm-svn: 145520

a 1-length character array.

llvm-svn: 145445

llvm-svn: 145421

declaration at namespace scope is followed by a semicolon and an open-brace
(or in C++, a 'try', ':' or '='), then the error is probably a function
definition with a spurious ';', rather than a mysterious '{'.

llvm-svn: 145372

whose enum has been made deprecated/unavailable in the warning.
// rdar://10201690

llvm-svn: 145264

This supports single-element initializer lists for references according to DR1288, as well as creating temporaries and binding to them for other initializer lists.

llvm-svn: 145186

llvm-svn: 145116

pointer mismatch.  Cases covered are: initialization, assignment, and function
arguments.  Additional text will give the extra information about the nature
of the mismatch: different classes for member functions, wrong number of
parameters, different parameter type, different return type, and function
qualifier mismatch.

llvm-svn: 145114

semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.

Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.

The -ftemplate-depth=N part of this fixes PR9890.

llvm-svn: 145045

and base-to-derived casts, and add proper handling of temporaries.

llvm-svn: 144926

llvm-svn: 144883

llvm-svn: 144700

lifetimes have been extended via reference binding. The type of the
reference and the type of the temporary are not necessarily the same,
which could cause a crash. Fixes <rdar://problem/10398199>.

llvm-svn: 144646

or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.

llvm-svn: 144468

to disable the corresponding -Wc++98-compat warnings in addition to the C++11
extension warnings, so that people already using these flags can switch to C++11
mode and turn on -Wc++98-compat.

llvm-svn: 144404

llvm-svn: 144382

stack pressure.

llvm-svn: 144378