A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,

The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType.  This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.

The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.   

Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh!

Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date.

Hopefully the third time;s a charm *fingers crossed*

This does not yet include capturing.

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193230 91177308-0d34-0410-b5e6-96231b3b80d8

They were causing CodeGenCXX/mangle-exprs.cpp to fail.

Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."

Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193226 91177308-0d34-0410-b5e6-96231b3b80d8

Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.

No change in functionality. 

In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. 

This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): 
http://llvm-reviews.chandlerc.com/D1856

Thanks!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193223 91177308-0d34-0410-b5e6-96231b3b80d8

modules.

With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193219 91177308-0d34-0410-b5e6-96231b3b80d8

lambdas nested within templates and themselves.

A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,


The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType.  This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.

The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.   

This does not yet include capturing.

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193216 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193210 91177308-0d34-0410-b5e6-96231b3b80d8

...rather than segfaulting.

Patch by Enrico P!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193208 91177308-0d34-0410-b5e6-96231b3b80d8

With this extension, friend function declarations will retain the language
linkage specified for previous declarations instead of emitting an error
diagnostic.

The feature is known to be compatible with GCC and MSVC and permits a
language to be specified indirectly where it cannot otherwise be written
directly in class scope.

Work is ongoing to improve linkage spec diagnostics.

Fixes PR17337.

Reviewed by Richard Smith.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193206 91177308-0d34-0410-b5e6-96231b3b80d8

check using the ubsan runtime) and -fsanitize=local-bounds (for the middle-end
check which inserts traps).

Remove -fsanitize=local-bounds from -fsanitize=undefined. It does not produce
useful diagnostics and has false positives (PR17635), and is not a good
compromise position between UBSan's checks and ASan's checks.

Map -fbounds-checking to -fsanitize=local-bounds to restore Clang's historical
behavior for that flag.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193205 91177308-0d34-0410-b5e6-96231b3b80d8

We would not identify pointer-to-member construction in a non-type
template argument if it was either a FieldDecl or a CXXMethodDecl.
However, this would incorrectly reject declarations that were injected
via an IndirectFieldDecl (e.g. a field inside of an anonymous union).

This fixes PR17657.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193203 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes pr17624.

A FIXME from Richard Smith:

It seems to me that the root cause is that a per-Decl 'used' flag doesn't
really make much sense in the way we use it now. I think we should either track
whether that particular declaration is used (with isUsed scanning the entire
redecl chain), or we should only have one flag for the entire redeclaration
chain (perhaps by always looking at the flag on either the most recent decl or
the canonical decl). Modeling it as "is this declaration or any previous
declaration used" is weird, and requires contortions like the loop at the end
of Sema::MarkFunctionReferenced.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193202 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes pr17639.

Before this patch clang would consider

void foo(void) __attribute((alias("__foo")));

a declaration. It now correctly handles it as a definition.

Initial patch by Alp Toker. I added support for variables.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193200 91177308-0d34-0410-b5e6-96231b3b80d8

This is a fixed version of r193161. In order to handle

    void foo() __attribute__((alias("bar")));
    void bar() {}
    void zed() __attribute__((alias("foo")));

it is not enough to delay aliases to the end of the TU, we have to do two
passes over them to find if they are defined or not.

This can be implemented by producing alias as we go and just doing the second
pass at the end. This has the advantage that other parts of clang that were
expecting alias to be processed in order don't have to be changed.

This patch also handles cyclic aliases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193188 91177308-0d34-0410-b5e6-96231b3b80d8

This is in line with implementation of _mm_extract_pi16.
rdar://15250497


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193187 91177308-0d34-0410-b5e6-96231b3b80d8

Some of the shared compiler/linker flags start with -m, so they've been
getting passed to the compiler only since r180073. Now, the -m* wildcard
is processed after the shared flags and the ignored flags.

Found by Laszlo Nagy!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193184 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewed at http://llvm-reviews.chandlerc.com/D1977

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193176 91177308-0d34-0410-b5e6-96231b3b80d8

This patch wasn't reviewed, and isn't correctly preserving the behaviors
relied upon by QT. I don't have a direct example of fallout, but it
should go through the standard code review process. For example, it
should never have removed the QT test case that was added when fixing
those users.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193174 91177308-0d34-0410-b5e6-96231b3b80d8

This is a fix to PR17649, caused by fix in r193073. QT uses 'break' statement
to implement their 'foreach' macro. To enable build of QT, this fix reenables
break but only in 'for' statement specifier and only in the third expression.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193170 91177308-0d34-0410-b5e6-96231b3b80d8

Style guide demands a two-space indent.

Before:
  NSArray *arguments = @[
      kind == kUserTicket ? @"--user-store" : @"--system-store",
      @"--print-tickets",
      @"--productid",
      @"com.google.Chrome"
  ];

After:
  NSArray *arguments = @[
    kind == kUserTicket ? @"--user-store" : @"--system-store",
    @"--print-tickets",
    @"--productid",
    @"com.google.Chrome"
  ];

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193168 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  NSArray *arguments =
      @[ kind == kUserTicket ? @"--user-store" : @"--system-store",
         @"--print-tickets", @"--productid", @"com.google.Chrome" ];
After:
  NSArray *arguments = @[
      kind == kUserTicket ? @"--user-store" : @"--system-store",
      @"--print-tickets",
      @"--productid",
      @"com.google.Chrome"
  ];

This fixes llvm.org/PR15231.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193167 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193166 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193164 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "This patch causes clang to reject alias attributes that point to undefined names. For example, with this patch we now reject"

This reverts commit r193161.

It broke

void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));

Looks like we have to fix pr17639 first :-(

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193162 91177308-0d34-0410-b5e6-96231b3b80d8

names. For example, with this patch we now reject

void f1(void) __attribute__((alias("g1")));

This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193161 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193154 91177308-0d34-0410-b5e6-96231b3b80d8

If we run into the second preprocessor branch chain, the first branch
chain might have already set the maximum branch count on that level to
something > 0.

Fixes PR17645.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193153 91177308-0d34-0410-b5e6-96231b3b80d8

This patch changes two things:

a) Allow a header to be part of multiple modules. The reasoning is that
in existing codebases that have a module-like build system, the same
headers might be used in several build targets. Simple reasons might be
that they defined different classes that are declared in the same
header. Supporting a header as a part of multiple modules will make the
transistion easier for those cases. A later step in clang can then
determine whether the two modules are actually compatible and can be
merged and error out appropriately. The later check is similar to what
needs to be done for template specializations anyway.

b) Allow modules to be stored in a directory tree separate from the
headers they describe.

Review: http://llvm-reviews.chandlerc.com/D1951

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193151 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Enforce the rule in C++11 [temp.mem]p2 that local classes cannot have
member templates.

This fixes PR16947.

N.B.  C++14 has slightly different wording to afford generic lambdas
declared inside of functions.

Fun fact:  Some formulations of local classes with member templates
would cause clang to crash during Itanium mangling, such as the
following:

void outer_mem() {
  struct Inner {
    template <typename = void>
    struct InnerTemplateClass {
      static void itc_mem() {}
    };
  };
  Inner::InnerTemplateClass<>::itc_mem();
}

Reviewers: eli.friedman, rsmith, doug.gregor, faisalv

Reviewed By: doug.gregor

CC: cfe-commits, ygao

Differential Revision: http://llvm-reviews.chandlerc.com/D1866

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193144 91177308-0d34-0410-b5e6-96231b3b80d8

Microsoft inline asm crashes on the hexagon bot for unknown reasons.

This reverts commit r193124.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193128 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193124 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r193100.

It was failing to compile with MSVC 2012 while instantiating
llvm::Optional<DynTypedMatcher>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193123 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193120 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193118 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193116 91177308-0d34-0410-b5e6-96231b3b80d8

Instead of using not, just drop the fastcall attribute which was causing
an warning:

calling convention 'fastcall' ignored for this target

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193110 91177308-0d34-0410-b5e6-96231b3b80d8

GCC does the same.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193103 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Refactor DynTypedMatcher into a value type class, just like Matcher<T>.
This simplifies its usage and removes the virtual hierarchy from Matcher<T>.
It also enables planned changes to replace MatcherInteface<T>.
Too many instantiaions of this class hierarchy has been causing Registry.cpp.o to bloat in size and number of symbols.

Reviewers: klimek

CC: cfe-commits, revane

Differential Revision: http://llvm-reviews.chandlerc.com/D1661

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193100 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193099 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Daniel Marjamäki.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193093 91177308-0d34-0410-b5e6-96231b3b80d8

Also fixes some funky formatting.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193079 91177308-0d34-0410-b5e6-96231b3b80d8