// rdar://9132143

llvm-svn: 129822

llvm-svn: 129820

redundancy pointed out by John.

llvm-svn: 129808

gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context
(e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed
is somewhat misleading.

- Don't emit 'unused' warnings for functions that are referenced in any part of the user's code.
- A warning that an internal function/variable won't get emitted is useful though, so introduce
  -Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not
  "needed" ('used' from the codegen perspective), e.g:

  static void foo() { }

  template <int>
  void bar() {
    foo();
  }

test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted
static void foo() { }
            ^

Addresses rdar://8733476.

llvm-svn: 129794

CL_AddressableVoid is the expression classification used for void
expressions whose address can be taken, i.e. the result of [], *
or void variable references in C, as opposed to things like the
result of a void function call.

llvm-svn: 129783

llvm-svn: 129741

llvm-svn: 129734

llvm-svn: 129728

llvm-svn: 129721

of conditional expressions of objc pointer types
where one type is the immediate base type of the
other. // rdar://9296866

llvm-svn: 129718

llvm-svn: 129712

llvm-svn: 129704

llvm-svn: 129703

Fix PR9741. The implicit declarations created for range-based for loops weren't being added to the DeclContext (nor were they being marked as implicit). Also, the declarations were being emitted in the wrong order when building the CFG.

llvm-svn: 129700

implementation such as

  @synthesize Prop1 = 

Give priority to ivars whose type matches or closely matches the
property type (as we do for several other kinds of
results). Additionally, if there is an ivar with the same name as the
property, or differs only due to a _ prefix or suffix, give that ivar
a priority bump. Finally, verify that this search is properly
returning ivars within class extensions and implementations
(<rdar://problem/8488854>).

llvm-svn: 129699

llvm-svn: 129698

implementation 

  @synthesize <property> = 

also produce a completion for a to-be-synthesized ivar named
_<property>.

llvm-svn: 129697

llvm-svn: 129682

it down.  we effectively were compile the testcase into:

void test14(int x) {
  switch (x) {
    case 11: break;
    case 42: test14(97);  // fallthrough
    default: test14(42); break;

which is not the same thing at all.  This fixes a miscompilation of 
MallocBench/gs seen on the clang-x86_64-linux-fnt buildbot.

llvm-svn: 129679

turns out that a field or base needs to be laid out in the tail padding of
the base, CGRecordLayoutBuilder::ResizeLastBaseFieldIfNecessary will convert
it to an array of i8.

I've audited the new test results to make sure that they are still valid. I've
also verified that we pass a self-host with this change.

This (finally) fixes PR5589!

llvm-svn: 129673

llvm-svn: 129671

llvm-svn: 129669

Use a SmallVector for field types in CGRecordLayoutBuilder now that llvm::StructType::get takes an ArrayRef.

llvm-svn: 129667

Also, fold the sse4 and sse4.1 cases together.

Patch by Alexander Best!

llvm-svn: 129665

properly.

llvm-svn: 129657

a -O0 code quality issue.

llvm-svn: 129652

are trivial.  This exposes opportunities earlier, and allows fastisel
to do good things with these at -O0.

This addresses rdar://9289468 - clang doesn't fold memset_chk at -O0

llvm-svn: 129651

fix rdar://9289603 - clang should fold trivial ?: for enums as well as integer constants into select at -O0
by making the isCheapEnoughToEvaluateUnconditionally predicate handle anything that folds to a constant.  In particular, we now fold enums.

llvm-svn: 129649

llvm-svn: 129629

Introduce Rewriter::IncreaseIndentation() which increase indentations for the lines between the given source range.
To determine what the indentation should be, a SourceLocation 'parentIndent' parameter is used that should be at
a source location with an indentation one degree lower than the given range.

llvm-svn: 129628

llvm-svn: 129626

llvm-svn: 129625

Add test case.

llvm-svn: 129617

// rdar://9287695

llvm-svn: 129615

llvm-svn: 129614

Objective-C pointer to void* as a "conversion to void*". This allows
us to prefer an Objective-C object pointer conversion to a superclass
object pointer over an Objective-C object pointer conversion to
cv-void*. Fixes PR9735.

llvm-svn: 129603

address space. I could see that this functionality would be useful,
but not in its current form (where the address space is ignored):
rather, we'd want to encode the address space into the parameter list
passed to operator new/operator delete somehow, which would require a
bunch more semantic analysis.

llvm-svn: 129593

"new" expression. This matches GCC's parser. Test is forthcoming.

llvm-svn: 129592

and output file is not writable. // rdar://9286457.

llvm-svn: 129587

dealing with address-space- and GC-qualified pointers. Previously,
these qualifiers were being treated just like cvr-qualifiers (in some
cases) or were completely ignored, leading to uneven behavior. For
example, const_cast would allow conversion between pointers to
different address spaces.

The new semantics are fairly simple: reinterpret_cast can be used to
explicitly cast between pointers to different address spaces
(including adding/removing addresss spaces), while
static_cast/dynamic_cast/const_cast do not tolerate any changes in the
address space. C-style casts can add/remove/change address spaces
through the reinterpret_cast mechanism. Other non-CVR qualifiers
(e.g., Objective-C GC qualifiers) work similarly.

As part of this change, I tweaked the "casts away constness"
diagnostic to use the term "casts away qualifiers". The term
"constness" actually comes from the C++ standard, despite the fact
that removing "volatile" also falls under that category. In Clang, we
also have restrict, address spaces, ObjC GC attributes, etc., so the
more general "qualifiers" is clearer.

llvm-svn: 129583