of that variable; it will need to be recomputed with the resolved
type.

llvm-svn: 150984

llvm-svn: 150983

name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.

Note that there are a several pieces still missing:
  - We still get the linkage of lambda expressions wrong
  - We aren't properly numbering or mangling lambda expressions that
  occur in default function arguments or in data member initializers.
  - We aren't (de-)serializing the lambda numbering tables

llvm-svn: 150982

handled by the caching and rauw. Also fix one cache that wasn't
being added to highlighted by this patch. Update all testcases
accordingly.

This should fix the deall failure.

llvm-svn: 150977

properly. Previously, we deserialized it but failed to set the
corresponding member in CXXNewExpr. Fixes <rdar://problem/10893600>.

llvm-svn: 150963

match the behavior of GCC. Also add a test for these intrinsics, which
apparently have *zero* tests. =[ Not surprisingly, Clang crashed when
compiling these.

Fix the bug in CodeGen where we failed to bitcast the argument type to
x86mmx prior to calling the LLVM intrinsic. This fixes an assert on the
new 3dnow-builtins.c test.

This is one issue impacting the efforts to get Clang to emulate the
Microsoft intrinsics headers -- 3dnow intrinsics are implictitly made
available there.

llvm-svn: 150948

actually matching the write substrings, and stop looking for a leading
'/' to try and finish fixing darwin and other hosts.

llvm-svn: 150938

llvm-svn: 150933

llvm-svn: 150932

llvm-svn: 150931

llvm-svn: 150930

Get recursive initializer lists to work and add a test. Codegen of std::initializer_list is now complete. Onward to array new.

llvm-svn: 150926

Add a testcase for using objects with list-constructors, and fix a Sema crash by repeating an old hack.

llvm-svn: 150925

llvm-svn: 150924

llvm-svn: 150923

llvm-svn: 150907

give up on matching the path prefix for the libraries.

llvm-svn: 150906

prefix.

llvm-svn: 150905

libraries on windows. Use two variables to make this test pass.

llvm-svn: 150903

llvm-svn: 150901

llvm-svn: 150900

configure's --with-gcc-toolchain. The configure option is now just a default
value for the command line one.

llvm-svn: 150898

llvm-svn: 150896

complex numbers. Treat complex numbers as arrays of the corresponding component
type, in order to make std::complex behave properly if implemented in terms of
_Complex T.

Apparently libstdc++'s std::complex is implemented this way, and we were
rejecting a member like this:

  constexpr double real() { return __real__ val; }

because it was marked constexpr but unable to produce a constant expression.

llvm-svn: 150895

Fix crash in analyzer diagnostic generation involving subexpressions of OpaqueValueExpr not appearing in the ParentMap.  Fixes <rdar://problem/10797980>.

llvm-svn: 150894

llvm-svn: 150892

Add analyzer test for using of C++ references with ObjC object pointers, reported in <rdar://problem/10569024>.

llvm-svn: 150891

rather than an lvalue referring to the scalar.

llvm-svn: 150889

Adopt ExprEngine and checkers to ObjC property refactoring.  Everything was working, but now diagnostics are aware of message expressions implied by uses of properties.  Fixes <rdar://problem/9241180>.

llvm-svn: 150888

This fixes PR5172 and allows clang to compile C++ programs on Solaris using the system headers.

llvm-svn: 150881

eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
captures.

This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.

The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.

The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.

llvm-svn: 150875

variable; it was previously duplicated, and one of the copies failed
to account for outer non-mutable lambda captures.

llvm-svn: 150872

are represented as prvalues in C++; don't be fooled into thinking they're
global lvalues.

llvm-svn: 150870

This should probably be refactored... but it isn't completely obvious what refactoring is best.

llvm-svn: 150869

llvm-svn: 150868

We had two separate issues here: firstly, varions functions were assuming that
they did not need to perform semantic checks on trivial destructors (this is
not true in C++11, where a trivial destructor can nonetheless be private or
deleted), and a bunch of DiagnoseUseOfDecl calls were missing for uses of
destructors.

llvm-svn: 150866

decent diagnostics. Finish the work of combining all the 'ShouldDelete'
functions into one. In unifying the code, fix a minor bug where an anonymous
union with a deleted default constructor as a member of a union wasn't being
considered as making the outer union's default constructor deleted.

llvm-svn: 150862

with full types if they exist.

rdar://10809898 and rdar://10209967 and rdar://10400981

llvm-svn: 150858

llvm-svn: 150847

it aware of CString APIs that return the input parameter.

Malloc Checker needs to know how the 'strcpy' function is
evaluated. Introduce the dependency on CStringChecker for that.
CStringChecker knows all about these APIs.

Addresses radar://10864450

llvm-svn: 150846