Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer t

Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.

* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.

llvm-svn: 226751

show more ...

Mark C++ reference parameters as dereferenceable

Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter

Mark C++ reference parameters as dereferenceable

Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.

Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.

llvm-svn: 213386

show more ...

Add 'nonnull' parameter or return attribute when producing an llvm pointer type in a function type where the C++ type is a reference. Update the tests.

llvm-svn: 209723

CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.

llvm-svn: 188447

More fixes for block mangling.

Make sure we properly treat names defined inside a block as local
names. There are basically three fixes here. One, correctly
treat blocks as a context where we need

More fixes for block mangling.

Make sure we properly treat names defined inside a block as local
names. There are basically three fixes here. One, correctly
treat blocks as a context where we need to use local-name mangling using
the new isLocalContainerContext helper. Two, make
CXXNameMangler::manglePrefix handle local names in a consistent way.
Three, extend CXXNameMangler::mangleLocalName so it can mangle a block
correctly.

llvm-svn: 185450

show more ...

Don't skip lambdas when mangling local vars.

This commit rearranges the logic in CXXNameMangler::mangleLocalName and
GetLocalClassDecl so that it doesn't accidentally skip over lambdas. It
also red

Don't skip lambdas when mangling local vars.

This commit rearranges the logic in CXXNameMangler::mangleLocalName and
GetLocalClassDecl so that it doesn't accidentally skip over lambdas. It
also reduces code duplication a bit.

llvm-svn: 185402

show more ...

Fix a small bug in the linkage computation for the lambda conversion-to-function-pointer member.

llvm-svn: 183931

Fix an edge case of mangling involving the combination of a lambda and typeid.
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expres

Fix an edge case of mangling involving the combination of a lambda and typeid.
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.

I would appreciate if someone would double-check that we get the mangling
correct with this patch.

llvm-svn: 164658

show more ...

Test for r164186.

llvm-svn: 164187

PR12917: Remove incorrect assumption that lambda mangling information cannot
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should

PR12917: Remove incorrect assumption that lambda mangling information cannot
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.

llvm-svn: 160614

show more ...

Move the computation of the lambda mangling information (mangling
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information i

Move the computation of the lambda mangling information (mangling
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.

Plus, actually mangle the context of lambdas properly.

llvm-svn: 154029

show more ...

Implement non-internal linkage for lambda closure types that need a
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
ca

Implement non-internal linkage for lambda closure types that need a
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
case, because it's already responsible for choosing the mangling
number.

llvm-svn: 151029

show more ...

Implement name mangling for lambda expressions that occur within the
initializers of data members (both static and non-static).

llvm-svn: 151017

Implement name mangling for lambda expressions that occur within the
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:

(1) Default arguments

Implement name mangling for lambda expressions that occur within the
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:

(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.

llvm-svn: 151011

show more ...

Basic support for name mangling of C++11 lambda expressions. Because
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each l

Basic support for name mangling of C++11 lambda expressions. Because
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

show more ...