-Wsometimes-uninitialized. This detects cases where an explicitly-written branch
inevitably leads to an uninitialized variable use (so either the branch is dead
code or there is an uninitialized use bug).

This chunk of warnings tentatively lives within -Wuninitialized, in order to
give it more visibility to existing Clang users.

llvm-svn: 157458

llvm-svn: 157440

backing two propeties because proprty names
match except for first letter being of different
case. // rdar://11528439, [PR12936].

llvm-svn: 157435

llvm-svn: 157434

Implement the C++11 discarded value expression rules for volatile lvalues.  <rdar://problem/10790820>.

llvm-svn: 157420

Where diagnostic about unfound property is not
issued in the context where a setter is looked up
in situation in which name and property name differ 
in their first letter case. // rdar://11363363

llvm-svn: 157407

volatile reference to a temporary is not viable. My interpretation is that
DR1152 was a bugfix, not a rule change for C++11, so this is not conditional on
the language mode. This matches g++'s behavior.

llvm-svn: 157370

Add a warning to diagnose statements in C++ like "*(volatile int*)x;".  Conceptually, this is part of -Wunused-value, but I added a separate flag -Wunused-volatile-lvalue so it doesn't get turned off by accident with -Wno-unused-value.  I also made a few minor improvements to existing unused value warnings in the process.  <rdar://problem/11516811>.

llvm-svn: 157362

Portions of this patch by Xi Wang. Reviewed by Jordy Rose. Thank you both.

Codegen support will follow soon.

llvm-svn: 157360

start with a cv-qualifier. DeclaratorDecl::getTypeSpecStartLoc() does not
produce the location of the first type-specifier (the cv-qualifier) in this
case, because we don't track source locations for cv-qualifiers.

No test here: I've not found a way to test this with a lit-style test, and
introducing a gtest test for this seems unwarranted. Suggestions welcome!

Patch by Daniel Jasper!

llvm-svn: 157311

on the RecordDecl.  Persist the MS portability type attributes and
ignore them in Sema rather than the parser.

Patch by João Matos!

llvm-svn: 157288

llvm-svn: 157194

provide a 'fixit' to change 'readonly' to 'readwrite'. // rdar://11448209

llvm-svn: 157193

llvm-svn: 157158

llvm-svn: 157139

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

llvm-svn: 157136

and provide a 'fixit' to change 'readonly' to 'readwrite'. 'fixit'
part needs little more work. // rdar://11448209

llvm-svn: 157121

llvm-svn: 157117

Simplify some users of DeclarationName::getNameKind. Fold getFETokenInfoAsVoid into its only caller.

llvm-svn: 157116

llvm-svn: 157114

accept the template argument expression as a type.

llvm-svn: 157085

warning. This also makes us warn on tags, which, ironically, is the only case
gcc warns on.

llvm-svn: 157039

that the methods have the same number of parameters, although we
certainly assumed this in many places. Objective-C can be insane
sometimes. Fixes <rdar://problem/11460990>.

llvm-svn: 157025

In the override search for Objective-C methods, protect against ASTs that have NULL interfaces behind a category, which can happen in invalid code. Fixes <rdar://problem/11478173>, a recent regression

llvm-svn: 157021

llvm-svn: 156987

about argument type mismatch.

This gives a nicer diagnostic in cases like
  printf(fmt,
         i);
where previously the snippet just pointed at 'fmt' (with a note at the
definition of fmt).

It's a wash for cases like
  printf("%f",
         i);
where previously we snippeted the offending portion of the format string,
but didn't indicate which argument was at fault.

llvm-svn: 156968

lambda as referring to a local in an enclosing scope if we're in the
enclosing scope of the lambda (not it's function call operator). Also,
turn the test into an IR generation test, since that's where the
crashes occurred. Really fixes PR12746 / <rdar://problem/11465120>.

llvm-svn: 156926

blocks and lambdas, based heavily on a patch from Meador Inge. Fixes
PR12746 / <rdar://problem/11465120>.

llvm-svn: 156925

llvm-svn: 156922

llvm-svn: 156916

No functionality change.

llvm-svn: 156914

llvm-svn: 156904

This improves the conversion diagnostics (by correctly pointing to the loop
construct for conversions that may've been caused by the contextual conversion
to bool caused by a condition expression) and also causes the NULL conversion
warnings to be correctly suppressed when crossing a macro boundary in such a
context. (previously, since the conversion context location was incorrect, the
suppression could not be performed)

Reported by Nico Weber as feedback to r156826.

llvm-svn: 156901

To do that, keep track of the location of the protocol id in the ObjCProtocolExpr
AST node.

rdar://11190837

llvm-svn: 156890

type and its accessor type and issue error if types
are incompatible, instead of crashing in IRgen.
// rdar://1105153

llvm-svn: 156871

This fixes the included test case & was reported by Nico Weber.

It's a little bit nasty using the difference in the conversion context, but
seems to me like a not unreasonable solution. I did have to fix up the
conversion context for conditional operators (it seems correct to me to include
the context for which we're actually doing the comparison - across all the
nested conditionals, rather than the innermost conditional which might not
actually have the problematic implicit conversion at all) and template default
arguments (this is a bit of a hack, since we don't have the source location of
the '=' anymore, so I just used the start of the parameter - open to
suggestions there)

llvm-svn: 156861

Previously we would reject it as illegal using a value of
enum type and on ObjC++ it was illegal to use an enumerator
as well.

rdar://11454917

llvm-svn: 156843

between property and its backing ivar.

llvm-svn: 156832

in r156825.

llvm-svn: 156831

Based on code review feedback by Jordan Rose.

llvm-svn: 156827