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

in a superclass and the protocols in a protocol list.

llvm-svn: 146615

llvm-svn: 146607

freebsd bots happy. In the longer term, we should have a mechanism for moving
constexpr recursion off the call stack, to support the default limit of 512
suggested by the standard.

llvm-svn: 146596

going to be a pointer-to-member constant. Fixes <rdar://problem/10544564>.

llvm-svn: 146587

matches gcc's behavior.

Fixes PR8186.

llvm-svn: 146586

I need to keep the test itself in the repository since it's the only way I can currently reproduce the issue.

llvm-svn: 146582

llvm-svn: 146580

llvm-svn: 146576

I cannot reproduce the failures neither on my machine nor on the same buildbot machine (with the clang binary built on it). Let's see if it fails again..

llvm-svn: 146574

is not visible, look for any previous declarations of that entity that
might be visible.

llvm-svn: 146563

llvm-svn: 146552

llvm-svn: 146544

llvm-svn: 146541

Some of the test cases do not currently work because the analyzer core
does not seem to call checkers for pre/post DeclRefExpr visits.
(Opened radar://10573500. To be fixed later on.)

llvm-svn: 146536

llvm-svn: 146533

Also, allow adding taint to a region (not only a symbolic value).

llvm-svn: 146532

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

llvm-svn: 146525

in classes. // rdar://10535349

llvm-svn: 146504

rdar://10567864&10567916

llvm-svn: 146497

@class forward references.

rdar://10568080&10568103&10568119

llvm-svn: 146496

llvm-svn: 146480

be constant expressions.

llvm-svn: 146479

llvm-svn: 146476

llvm-svn: 146454

Necessary to parse Microsoft ATL code.

Example: 
  int array[] = {
    0, 
    __if_exists(CLASS::Type) {2, }
    3
  };

will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.

llvm-svn: 146447

inside a struct/union.

llvm-svn: 146444

Make CGRecordLayoutBuilder correctly switch over to a packed class when a class has a base whose alignment will break the class layout.  <rdar://problem/10551376>.

llvm-svn: 146443

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

fields by just following what comment says.
// rdar://10513599

llvm-svn: 146414

conversions in constant expressions.

llvm-svn: 146406

the subdirectories to find headers in submodules.

llvm-svn: 146398

llvm-svn: 146395

actually a terribly good heuristic, and the world is too horrible for
it to work.

llvm-svn: 146393

llvm-svn: 146392

llvm-svn: 146390

llvm-svn: 146371

llvm-svn: 146367

llvm-svn: 146354

[analyzer] CStringChecker should not rely on the analyzer generating UndefOrUnknown value when it cannot reason about the expression.

We are now often generating expressions even if the solver is not known to be able to simplify it. This is another cleanup of the existing code, where the rest of the analyzer and checkers should not base their logic on knowing ahead of the time what the solver can reason about. 

In this case, CStringChecker is performing a check for overflow of 'left+right' operation. The overflow can be checked with either 'maxVal-left' or 'maxVal-right'. Previously, the decision was based on whether the expresion evaluated to undef or not. With this patch, we check if one of the arguments is a constant, in which case we know that 'maxVal-const' is easily simplified. (Another option is to use canReasonAbout() method of the solver here, however, it's currently is protected.)

This patch also contains 2 small bug fixes:
 - swap the order of operators inside SValBuilder::makeGenericVal.
 - handle a case when AddeVal is unknown in GenericTaintChecker::getPointedToSymbol.

llvm-svn: 146343