whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.

This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.

Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.

llvm-svn: 121831

llvm-svn: 121821

llvm-svn: 121795

the basic casting logic to insert intermediate casts and preserve the
exact complex-cast design.  Fixes a crash in the test suite.

llvm-svn: 121776

llvm-svn: 121771

by valgrind where we were doing the wrong thing in the presence of invalid
exception specs.

llvm-svn: 121770

llvm-svn: 121768

llvm-svn: 121763

llvm-svn: 121759

class to be passed around.  The line between argument and return types and
everything else is kindof vague, but I think it's justifiable.

llvm-svn: 121752

llvm-svn: 121742

llvm-svn: 121734

and TemplateArgument with an operation that determines whether there
are any unexpanded parameter packs within that construct. Use this
information to diagnose the appearance of the names of parameter packs
that have not been expanded (C++ [temp.variadic]p5). Since this
property is checked often (every declaration, ever expression
statement, etc.), we extend Type and Expr with a bit storing the
result of this computation, rather than walking the AST each time to
determine whether any unexpanded parameter packs occur.

This commit is deficient in several ways, which will be remedied with
future commits:
  - Expr has a bit to store the presence of an unexpanded parameter
  pack, but it is never set.
  - The error messages don't point out where the unexpanded parameter
  packs were named in the type/expression, but they should. 
  - We don't check for unexpanded parameter packs in all of the places
  where we should.
  - Testing is sparse, pending the resolution of the above three
  issues.

llvm-svn: 121724

llvm-svn: 121720

llvm-svn: 121694

would return true if the initializer pointer union had *any* non-null
pointer in it, even if the pointer wasn't one that would actually be
returned via getInit(). This makes it more accurately model the logic of
'getInit() != NULL'.

This still isn't completely satisfying. From a principled stance,
I suspect we should make hasInit() and getInit() *always* return false
and NULL (resp.) for ParmVarDecl. We shouldn't at the API level treat
initializers and default arguments as the same thing.

llvm-svn: 121692

cases. First, omit all builtin overloads when no non-record type is in the set
of candidate types. Second, avoid arithmetic type overloads for non-arithmetic
or enumeral types (counting vector types as arithmetic due to Clang
extensions). When heavily using constructs such as STL's '<<' based stream
logging, this can have a significant impact. One logging-heavy test case's
compile time dropped by 10% with this. Self-host shows 1-2% improvement in
compile time, but that's likely in the noise.

llvm-svn: 121665

llvm-svn: 121654

llvm-svn: 121653

a translation unit to the ActOnEndOfTranslationUnit function instead of doing
it at the start of DefineUsedVTables. The latter is now called *recursively*
during template instantiation, which causes an absolutely insane number of
walks of every record decl in the translation unit.

After this patch, an extremely template instantiation heavy test case's compile
time drops by 10x, and we see between 15% and 20% improvement in average
compile times across a project. This is just recovering a regression, it
doesn't make anything faster than it was several weeks ago.

llvm-svn: 121644

llvm-svn: 121640

candidates. They're now wrapped in nice APIs which hide the tables, etc. Also
removes some repetitive code from clients.

llvm-svn: 121634

type. Localize all of the logic within a single function rather than spreading
it throughout the class.

Also fixes a buglet where we failed to check for a RHS arithmetic type wider
than the LHS and return its canonical type. I've yet to produce a test case
that breaks because of this, but it was spotted by inspection by folks on the
IRC channel and is obviously correct now.

llvm-svn: 121633

llvm-svn: 121632

user-defined operator overloads on the same enumeral types to the one place
where it is used.

In theory this removes wasted computation from several paths through this code,
but I'm not aware of a case where it actually matters. This is mostly for
cleanliness.

llvm-svn: 121630

others have another ordering they would prefer, I'm all ears, but this one made
it much easier for me to find the group of operators I'm interested in.

llvm-svn: 121629

added for binary operator&.

llvm-svn: 121628

llvm-svn: 121627

from the switch statement.

llvm-svn: 121626

for a few cases.

llvm-svn: 121625

llvm-svn: 121624

candidate set. This breaks apart a huge switch + goto system into distinct
methods on a class. It also places the current mess of tables and other static
state used in the process within that class.

This is still a work in progress. I did a few simplifications that jumped out
at me as I went, but I plan to iterate on this a bit before it's truly clean.
However, this is easily the most invasive chunk. I benchmarked it on
all-std-headers.cpp and an internal testcase that has a major hotspot in
overload resolution and saw no real performance impact.

llvm-svn: 121623

for declaration of property setter/getter in forward
class extensions and also skip over
propeties which are @dynamic.

llvm-svn: 121617

llvm-svn: 121616

declared setter or getter in current class extension or one
of the other class extensions. Mark them as synthesized as
property will be synthesized when property with same name is
seen in the @implementation. This prevents bogus warning
about unimplemented methods to be issued for these methods.
Fixes // rdar://8747333

llvm-svn: 121597

llvm-svn: 121595

The 64-bit element vectors need to be handled as a special case.

llvm-svn: 121592

llvm-svn: 121517

llvm-svn: 121516

llvm-svn: 121515