Commit Graph

12 Commits

Author SHA1 Message Date
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Eli Friedman 95f501284a 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
2013-07-02 17:52:28 +00:00
Eli Friedman 92821745bf 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
2013-07-02 02:01:18 +00:00
Eli Friedman 8f54e136f4 Fix a small bug in the linkage computation for the lambda conversion-to-function-pointer member.
llvm-svn: 183931
2013-06-13 19:39:48 +00:00
Eli Friedman 15681d6852 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
2012-09-26 04:34:21 +00:00
Eli Friedman 2b4896ff8e Test for r164186.
llvm-svn: 164187
2012-09-19 01:35:20 +00:00
Richard Smith 505df2340a 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
2012-07-22 23:45:10 +00:00
Douglas Gregor b61e809b42 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
2012-04-04 17:40:10 +00:00
Douglas Gregor 6f88e5e0d7 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
2012-02-21 04:17:39 +00:00
Douglas Gregor 926410d2db Implement name mangling for lambda expressions that occur within the
initializers of data members (both static and non-static).

llvm-svn: 151017
2012-02-21 02:22:07 +00:00
Douglas Gregor 7fcbd902b4 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
2012-02-21 00:37:24 +00:00
Douglas Gregor 6379854457 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
2012-02-20 19:44:39 +00:00