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

A raw lexer in its initial state is guaranteed to be on line number one.

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

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

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

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

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

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

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

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

Giving a Subjects list to DllExport, which allows the removal of some custom semantic handling. The same cannot be done for DllImport, and so comments were left explaining why.

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

Common functionality is already checked within SemaDeclAttr.cpp and so it does not need to be re-checked for each target.

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

Fixes the relevant FIXME about copy-pasted code.

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

Clang currently croaks on the following:
  struct X1 {
    struct X2 {
      int L = ([] (int i) { return i; })(2);
    };
  };

asserting that the containing lexical context of the lambda is not Sema's cur context, when pushing the lambda's decl context on.

This occurs because (prior to this patch) getContainingDC always returns the non-nested class for functions at class scope (even for inline member functions of nested classes (to account for delayed parsing of their bodies)).  The patch addresses this by having getContainingDC always return the lexical DC for a lambda's call operator.

Link to the bug: http://llvm.org/bugs/show_bug.cgi?id=18052
Link to Richard Smith's feedback on phabricator: http://llvm-reviews.chandlerc.com/D2331

Thanks!

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

The MSP430Interrupt attribute does have a sema handler (it's in TargetAttributesSema). Added a FIXME about the attribute being nameless when it really does have a valid name, and a comment explaining why we're using the name instead of the attribute kind.

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

Getting rid of some hard-coded strings. No functional changes intended, though some test cases needed to be updated for attribute names becoming quoted.

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

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

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

which specifies couple of (optional) method selectors
for bridging a CFobject to or from an ObjectiveC 
object. This is wip. // rdsr://15499111


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

Enea Zaffanella's fix for the PPCallbacks Elif callback, with a slight re-org, and an update of the new PPCallbacks test (soon to be moved to clang from extra), rather the unittest.

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

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

Summary:
MSVC destroys arguments in the callee from left to right.  Because C++
objects have to be destroyed in the reverse order of construction, Clang
has to construct arguments from right to left and destroy arguments from
left to right.

This patch fixes the ordering by reversing the order of evaluation of
all call arguments under the MS C++ ABI.

Fixes PR18035.

Reviewers: rsmith

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

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

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

When parsing ignored attribute arguments, presuming the first argument is an unresolved identifier the same way that we do for unknown arguments. This resolves PR18075, where we regressed the handling of OpenBSD's bounded attribute.

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

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

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

Summary:
Allow tryFitMultipleLinesInOne join unwrapped lines when
ContinuationIndenter::mustBreak doesn't agree. But don't merge any lines, that
are separate in the input.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

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

It broke clang tests on some hosts with +Asserts. Seems "STDC" clashes.

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

And refactor to have just one place in code that sets up the empty
pragma handlers.



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

I'd misunderstood getIndirect() to mean that the argument should be passed
as a pointer at the ABI level, with the ByVal argument choosing caller-copy
semantics over no-caller-copy (callee-copy-on-write) semantics.  But
getIndirect(x) actually means that x is passed by pointer at the IR
level but (at least on all other targets I looked at) directly at the
ABI level.  getIndirect(x, false) selects a pointer to a caller-made
copy, which is what SystemZ was aiming for.

This fixes a miscompilation of c-index-test.  Structure arguments were being
passed by pointer, but no copy was being made, so a write in the callee
stomped over a caller's local variable.


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

We would lose track of the mangling number assigned to the original
declaration which would cause us to create manglings that didn't match
the Itanium C++ specification.

e.g. Two static fields with the same name inside of a function template
would receive the same mangling with LLVM fixing up the second field so
they wouldn't collide.  This would create an incompatibility with other
compilers following the Itanium ABI.

I've confirmed that the new mangling is identical to the ones generated
by icc and gcc.

N.B. This was uncovered while working on Microsoft mangler.


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

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

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

This patch fixes PR16989.


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

In delayed template parsing mode, adjust the template depth counter for each template parameter list associated with an out of line member template specialization.


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

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

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

clang/test/CodeGen/builtins-nvptx.c: Prune "REQUIRES: nvptx64-registered-target". "nvptx" should imply it.

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

In trunk, we can use features as below:

  aarch64-registered-target
  hexagon-registered-target
  msp430-registered-target
  r600-registered-target
  systemz-registered-target
  xcore-registered-target

Each of them, as below, implies corresponding subtargets:

  arm-registered-target   -- arm, thumb
  mips-registered-target  -- mips, mips64, mips64el, mipsel
  nvptx-registered-target -- nvptx, nvptx64
  sparc-registered-target -- sparc, sparcv9
  x86-registered-target   -- x86, x86-64

They will be renamed:

  cppbackend-registered-target -- was "cpp". Unused in trunk.
  powerpc-registered-target -- was "ppc32", "ppc64" and "ppc64le".

The feature "asserts" is also taken from llvm-config.

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

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

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