llvm-svn: 148774

llvm-svn: 148772

llvm-svn: 148765

matches a typedef declaring an object type. // rdar://10733000

llvm-svn: 148760

type of pointers. 

llvm-svn: 148753

its line. // rdar://10711037

llvm-svn: 148747

llvm-svn: 148744

Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.

llvm-svn: 148735

Sema::DiagnoseSentinelCalls() does.

llvm-svn: 148722

Previously, for unqualified lookups, a positive cache hit is used as the
only non-keyword correction and a negative cache hit immediately returns
an empty TypoCorrection. With the new callback objects, this behavior
causes false negatives by not accounting for the fact that callback
objects alter the set of potential/allowed corrections. The new behavior
is to seed the set of corrections with the cached correction (for
positive hits) to estabilishing a baseline edit distance. Negative cache
hits are only stored or used when either no callback object is provided
or when it returns true for a call to ValidateCandidate with an empty
TypoCorrection (i.e. when ValidateCandidate does not seem to be doing
any checking of the TypoCorrection, such as when an instance of the base
callback class is used solely to specify the set of keywords to be accepted).

llvm-svn: 148720

llvm-svn: 148711

without C++-specific features.

Use it to set the language to C++ when indexing non-C-like structs.
rdar://10732579

llvm-svn: 148708

of macro arguments.

For "MAC1( MAC2(foo) )" and location of 'foo' token it would return
"MAC1" instead of "MAC2".

llvm-svn: 148704

expression) when code-completing member access expressions. Fixes
<rdar://problem/10717172>.

llvm-svn: 148703

to an error, so that users can turn them off if necessary. Note that
this does *not* change the behavior of in a SFINAE context, where we
still flag an error even if the warning is disabled. This matches
GCC's behavior.

llvm-svn: 148701

X86 backend in LLVM.

llvm-svn: 148689

llvm-svn: 148683

This matches cl.exe's behavior and fixes PR11791.

llvm-svn: 148682

Clang previously implemented -Wswitch-enum the same as -Wswitch. This patch
corrects the behavior to match GCC's. The critical/only difference being that
-Wswitch-enum is not silenced by the presence of a default case in the switch.

llvm-svn: 148679

Also change a || that I accidentally changed to && back to ||.

llvm-svn: 148677

MSVC2010's pair class has a move assignment operator but no explicit copy
constructor, which makes it unusable without this change.

For symmetry, let move copy constructors not mark the default assignment
operator as deleted either. Both changes match cl.exe's behavior.  Fixes
pr11826.

Also update the standard excerpt to point to the right paragraph.

llvm-svn: 148675

llvm-svn: 148673

For consistency with GCC & reasonable sanity. The FIXME suggests that the
original author was perhaps using the default check for some other purpose,
not realizing the more obvious limitation/false-negatives it creates, but this
doesn't seem to produce any regressions & fixes the included test.

llvm-svn: 148649

In Microsoft Mode, disable the C++11 strict integral conversion rules for enumerator that were introduced with r148439. Otherwise MSVC headers won't compile in C++ 11 mode.

llvm-svn: 148642

This warning acts as the complement to the main -Wswitch-enum warning (which
warns whenever a switch over enum without a default doesn't cover all values of
 the enum) & has been an an-doc coding convention in LLVM and Clang in my
experience. The purpose is to ensure there's never a "dead" default in a
switch-over-enum because this would hide future -Wswitch-enum errors.

The name warning has a separate flag name so it can be disabled but it's grouped
under -Wswitch-enum & is on-by-default because of this.

The existing violations of this rule in test cases have had the warning disabled
& I've added a specific test for the new behavior (many negative cases already
exist in the same test file - and none regressed - so I didn't add more).

Reviewed by Ted Kremenek ( http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120116/051690.html )

llvm-svn: 148640

llvm-svn: 148637

llvm-svn: 148636

[analyzer] It's possible to have a non PointerType expression evaluate to a Loc value. When this happens, use the default type.

llvm-svn: 148631

llvm-svn: 148628

Also, slightly modify the diagnostic message in ArrayBound and DivZero (still use 'taint', which might not mean much to the user, but plan on changing it later).

llvm-svn: 148626

Add an assertion that our use-marking actually covers all uses of a variable.  The assertion doesn't cover quite as much as it should, but it's a good start, at least.

llvm-svn: 148625

Fix some comments relating to ExpressionEvaluationContexts.  Get rid of a couple of uses of ConstantEvaluated which don't make sense.

llvm-svn: 148624

function body.  This keeps the brace count accurate to prevent
additional errors.  Also, moved the caret from the brace to the function
name.

Code:
class F{ int Foo{ return 1; } };

Fixed error:
parameters.cc:1:14: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
             ^
1 error generated.

Old errors:
parameters.cc:1:17: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
                ^
parameters.cc:1:30: error: expected ';' after class
class F{ int Foo{ return 1; } };
                             ^
                             ;
parameters.cc:1:31: error: expected external declaration
class F{ int Foo{ return 1; } };
                              ^
3 errors generated.

llvm-svn: 148621

llvm-svn: 148611

Make clang's AST model sizeof and typeof with potentially-evaluated operands correctly, similar to what we already do with typeid.

llvm-svn: 148610

to "strong" when migrating from GC. // rdar://10532449

llvm-svn: 148607

argument, which was broken and very ugly (and even had a test case to
make *sure* it was broken and ugly). Fixes <rdar://problem/10609117>.

llvm-svn: 148606

llvm-svn: 148599

llvm-svn: 148595

llvm-svn: 148592