Reject template-ids containing literal-operator-ids that have a dependent
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196443 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify the constructor to CodeGenABITypes.

The CodeGenOptions are not used for ABI type selection, so we will just
create one with the default constructor (there is a FloatABI option in
CodeGenOptions that is passed on to LLVM, but not used in Clang for LLVM
IR type generation).

We can use the DiagnosticsEngine on the ASTContext rather than making a
client pass one in explicitly.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196450 91177308-0d34-0410-b5e6-96231b3b80d8
Add an AdjustedType sugar node for adjusting calling conventions

Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar.  The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.

Fixes PR17996.

Reviewers: rsmith

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196451 91177308-0d34-0410-b5e6-96231b3b80d8
Parse: Recover better from bad definitions with base specifiers

We would skip until the next comma, hoping good things whould lie there,
however this would fail when we have such things as this:

struct A {};
template <typename>
struct D;
template <>
struct D<C> : B, A::D;

Once this happens, we would believe that D with a nested namespace
specifier of A was a variable that was being declared. We would go on
to complain that there was an extraneous 'template <>' on their variable
declaration.

Crashes would happen when 'A' gets defined as 'enum class A {}' as
various asserts would fire.

Instead, we should skip up until the semicolon if we see that we are in
the middle of a definition and the current token is a ':'

This fixes PR17084.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196453 91177308-0d34-0410-b5e6-96231b3b80d8
Fix init-captures for generic lambdas.

For an init capture, process the initialization expression
right away.  For lambda init-captures such as the following:
const int x = 10;
 auto L = [i = x+1](int a) {
   return [j = x+2,
          &k = x](char b) { };
 };
keep in mind that each lambda init-capture has to have:
 - its initialization expression executed in the context
   of the enclosing/parent decl-context.
 - but the variable itself has to be 'injected' into the
   decl-context of its lambda's call-operator (which has
   not yet been created).
Each init-expression is a full-expression that has to get
Sema-analyzed (for capturing etc.) before its lambda's
call-operator's decl-context, scope & scopeinfo are pushed on their
respective stacks.  Thus if any variable is odr-used in the init-capture
it will correctly get captured in the enclosing lambda, if one exists.
The init-variables above are created later once the lambdascope and
call-operators decl-context is pushed onto its respective stack.

Since the lambda init-capture's initializer expression occurs in the
context of the enclosing function or lambda, therefore we can not wait
till a lambda scope has been pushed on before deciding whether the
variable needs to be captured.  We also need to process all
lvalue-to-rvalue conversions and discarded-value conversions,
so that we can avoid capturing certain constant variables.
For e.g.,
 void test() {
  const int x = 10;
  auto L = [&z = x](char a) { <-- don't capture by the current lambda
    return [y = x](int i) { <-- don't capture by enclosing lambda
         return y;
    }
  };
If x was not const, the second use would require 'L' to capture, and
that would be an error.
Make sure TranformLambdaExpr is also aware of this.

Patch approved by Richard (Thanks!!) 
http://llvm-reviews.chandlerc.com/D2092

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196454 91177308-0d34-0410-b5e6-96231b3b80d8
Fix non-MSVC build error in ASTContext::getAdjustedType

Use FunctionTypeUnwrapper like we do in AttributedType to try to keep
some sugar.  We can actually do one better here in the future by
avoiding the AdjustedType node altogether when no sugar would be lost.

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