giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types. 

Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved 
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.

As part of this, some types have been renamed:

  TypeOfExpr -> TypeOfExprType
  FunctionTypeProto -> FunctionProtoType
  FunctionTypeNoProto -> FunctionNoProtoType

There shouldn't be any functionality change...

llvm-svn: 65591

but in C99 it is just another int type.

llvm-svn: 65590

initialization of wchar_t arrays with wide strings, and generalizes
wchar_size.c to work on all targets.

llvm-svn: 65586

llvm-svn: 65583

nicely sugared type that shows how the user wrote the actual
specialization. This sugared type won't actually show up until we
start doing instantiations.

llvm-svn: 65577

 - For types whose native representation is a pointer.

 - Use to replace ExprConstant.cpp:HasPointerEvalType,
   CodeGenFunction::isObjCPointerType.

llvm-svn: 65569

 - Having pointers and references share a base was not a useful
   notion.

llvm-svn: 65567

llvm-svn: 65529

Also changed ObjCInterfaceDecl::lookupClassMethod() to look through a categories protocols.

Test/patch submitted by Jean-Daniel Dupas (thanks!).

llvm-svn: 65526

pretty sure we want to keep constant expression verification outside of 
Evaluate. Because of that, the short-circuit evaluation doesn't 
generally make sense, and the comma warning doesn't make sense in its 
current form.

llvm-svn: 65525

is a rather big change, but I think this is the direction we want to go; 
the code is significantly shorter now, and it doesn't duplicate Evaluate 
code.  There shouldn't be any visible changes as far as I know.

There has been some movement towards putting ICE handling into 
Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate 
instead of isICE).  This patch is sort of the opposite of the approach, 
making ICE handling work without Evaluate being aware of it. I think 
this approach is better because it separates the code that does the 
constant evaluation from code that's calculating a rather 
arbitrary predicate.

The one thing I don't really like about this patch is that 
the handling of commas in C99 complicates it signficantly. (Seriously, 
what was the standards committee thinking when they wrote that 
part?) I think I've come up with a decent approach, but it doesn't feel
ideal.  I might add some way to check for evaluated commas from Evaluate 
in a subsequent patch; that said, it might not be worth bothering.

llvm-svn: 65524

llvm-svn: 65519

llvm-svn: 65489

specializations. In particular:

  - Make sure class template specializations have a "template<>"
    header, and complain if they don't.
  - Make sure class template specializations are declared/defined
    within a valid context. (e.g., you can't declare a specialization
    std::vector<MyType> in the global namespace).

llvm-svn: 65476

  std::vector<int>::allocator_type

When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:

  template<> class Outer::Inner<int> { ... };

We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.

Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.

llvm-svn: 65467

only from a function definition (that does not have a prototype) are
only used to determine the compatible with other declarations of that
same function. In particular, when referencing the function we pretend
as if it does not have a prototype. Implement this behavior, which
fixes PR3626.

llvm-svn: 65460

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

lookup to skip over names without linkage. This finishes
<rdar://problem/6127293>.

llvm-svn: 65386

  - When we are declaring a function in local scope, we can merge with
    a visible declaration from an outer scope if that declaration
    refers to an entity with linkage. This behavior now works in C++
    and properly ignores entities without linkage.
  - Diagnose the use of "static" on a function declaration in local
    scope.
  - Diagnose the declaration of a static function after a non-static
    declaration of the same function.
  - Propagate the storage specifier to a function declaration from a
    prior declaration (PR3425)
  - Don't name-mangle "main"

llvm-svn: 65360

of a pointer to object; This patch does this odd behavior according to
gcc.

llvm-svn: 65334

Remove support for "Class<P>". Will be making this an error.

llvm-svn: 65332

llvm-svn: 65331

llvm-svn: 65305

Contains the following (related to problems found while investigting <rdar://problem/6497631> Message lookup is sometimes different than gcc's).

- Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default).
- Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol).
- Changed several test cases to jive with the above changes.

llvm-svn: 65292

true a local pointer to objective-c object in generating
write barriers.

llvm-svn: 65290

someone would reasonably expect Evaluate to handle for C/ObjC.

llvm-svn: 65284

I know, these follow the exact same rules as pointers, so I just made 
them use the same codepath.  Someone more familiar with ObjC should 
double-check this, though.

llvm-svn: 65261

partially done in r65258.)

llvm-svn: 65260

PR3254 and part of PR3433.

The isICE changes are necessary to keep the computed results 
consistent with Evaluate.

llvm-svn: 65258

llvm-svn: 65255

This is necessary 'plumbing' to fix <rdar://problem/6497631> Message lookup is sometimes different than gcc's.

llvm-svn: 65248

Found while researching <rdar://problem/6497631> Message lookup is sometimes different than gcc's.

Will never be seen in user code. Needed to pass dejagnu testsuite.

llvm-svn: 65244

llvm-svn: 65235

expr; hilarity ensued.
 - PR3640.

llvm-svn: 65234

Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK?  I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).

llvm-svn: 65233

This fixes <rdar://problem/6497650> More type mismatches issues with clang.

Move two key ObjC typechecks from Sema::CheckPointerTypesForAssignment() to ASTContext::mergeTypes().

This allows us to take advantage of the recursion in ASTContext::mergeTypes(), removing some bogus warnings.

This test case I've added includes an example where we still warn (and GCC doesn't). Need to talk with folks and decide what to do. At this point, the major bogosities should be fixed.

llvm-svn: 65231

with new/delete.  With disable-free, this reduces the number of 4/8 byte
mallocs from 4793/1541 to 865/456 and also drops other sizes as well.

This is a very small perf win, nothing major.

llvm-svn: 65171

but don't start using it yet.  Renamed some methods to be more consistent.

llvm-svn: 65168

llvm-svn: 65166

before the dtor.

llvm-svn: 65156