This allows the ObjFW runtime to correctly implement message forwarding
for messages which return a struct.

Patch by Jonathan Schleifer.

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

It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long.  So C99 conformance requires not conforming to C99. :)

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

Also, fix the wording to reflect this.

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

They seemed to have the same implications, and this makes for one
less flag to worry about.

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

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

sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.

The fix here has two parts:

1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.

2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.

There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.


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

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

Previously, we tried to avoid creating new temporary object regions if
the value to be materialized itself came from a temporary object region.
However, once we became more strict about lvalues vs. rvalues (months
ago), this optimization became dead code, because the input to this
function will always be an rvalue (i.e. a symbolic value or compound
value rather than a region, at least for structs).

This would be a nice optimization to keep, but removing it makes it
simpler to reason about temporary regions.

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

Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)

I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.

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

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

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

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

This goes with r186925, which reverted Pavel's commit in r186498.

Also, add a correctness test for the future.

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

PR16690

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

This only makes a difference with broken versions of env (like the one in
gnutools32) that always return 0.

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

The reason this clang invocation was failing is that it had two %s. We would
close stdout after the first one and report a fatal error when trying to
print the second.

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

Before:
  #define OPERATION_CASE(name) \
    case OP_name:              \
    return operations::Operation##name

  switch (OpCode) {
      CASE(Add);
      CASE(Subtract);
    default:
      return operations::Unknown;
  }

After:
  #define OPERATION_CASE(name) \
    case OP_name:              \
      return operations::Operation##name;

  switch (OpCode) {
    CASE(Add);
    CASE(Subtract);
    default:
      return operations::Unknown;
  }

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

In TUs with large classes, a matcher like

  methodDecl(ofClass(recordDecl(has(varDecl()))))

(finding all member functions of classes with static variables)
becomes unbearably slow otherwise.

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

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

BalancedDelimiterTracker::diagnoseOverflow calls P.SkipUntil, and before this
patch P.SkipUnti is recursive, causing problems on systems with small stacks.
This patch fixes it by making P.SkipUnti non recursive when just looking for
eof.

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

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

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

only affect functions without a separate return block. This fixes the
linetable for void functions with cleanups and multiple returns.

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

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

via a macro, try using declaration's starting location.
This is improvement over not having a valid location and
dropping comment altogether. // rdar://14348912


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

getToolChain().getTriple().getArch() can be replaced by getToolChain().getArch()



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

r186899 and r187061 added a preferred way for some architectures not to get
intrinsic generation for math builtins. So the code changes in r185568 can
now be undone (the test remains).



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

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

of an artificial function gets an artificial location as well.

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

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

Expose static type of init/alloc/retain with
instance type as well. Ad-hoc cases are coming
next.


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

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

migrating to instancetype can have implicit 'id'
type too.


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

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

cxx_init_capture. "generalized" is neither descriptive nor future-proof. No
compatibility problems expected, since we've never advertised having this
feature.


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

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

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

Before this change, Clang uses the x86 representation for C++ method
pointers when generating code for PNaCl.  However, the resulting code
will assume that function pointers are 0 mod 2.  This assumption is
not safe for PNaCl, where function pointers could have any value
(especially in future sandboxing models).

So, switch to using the ARM representation for PNaCl code, which makes
no assumptions about the alignment of function pointers.

Since we're changing the "le32" target, this change also applies to
Emscripten.  The change is beneficial for Emscripten too.  Emscripten
has a workaround to make function pointers 0 mod 2.  This change would
allow the workaround to be removed.

See: https://code.google.com/p/nativeclient/issues/detail?id=3450

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

No functionality change.

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

Summary:
Add support for Adaptative matchers on the dynamic registry.
Each adaptative matcher is created with a function template. We instantiate the function N times, one for each possible From type and apply the techniques used on argument overloaded and polymorphic matchers to add them to the registry.

Reviewers: klimek

CC: cfe-commits, revane

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

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

This is far from implementing all the rules given by
http://www.webkit.org/coding/coding-style.html

The important new feature is the support for styles that don't have a
column limit. For such styles, clang-format will (at the moment) simply
respect the input's formatting decisions within statements.

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

objects to be used once their lifetimes end. This completes the C++1y
constexpr extensions.


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