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

llvm-svn: 65589

llvm-svn: 65587

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

llvm-svn: 65586

Unfortunately this doesn't work yet because wchar_t is completely
broken in C.

llvm-svn: 65585

llvm-svn: 65584

llvm-svn: 65583

llvm-svn: 65582

output).
 - For timing IRgen phase.

llvm-svn: 65580

llvm-svn: 65579

llvm-svn: 65578

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

llvm-svn: 65574

(This is not yet used.)

llvm-svn: 65573

llvm-svn: 65571

know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:

  - Insert some new code (a text string) at a particular source
    location
  - Remove the code within a given range
  - Replace the code within a given range with some new code (a text
    string)

Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:

  template<int I> class B { };
  B<1000 >> 2> *b1;

we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:

test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
  B<1000 >> 2> *b1;
         ^
    (        )


Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.

In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.

This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).

llvm-svn: 65570

 - For types whose native representation is a pointer.

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

llvm-svn: 65569

llvm-svn: 65568

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

llvm-svn: 65567

pointer type.
 - Drops use of PointerLikeType.
 - No intended functionality change.

llvm-svn: 65566

llvm-svn: 65565

friends should work.  This fixes 2006-11-30-Pubnames.cpp and friends on darwin
with the new -mmacosx-version-min change.

llvm-svn: 65564

 - No functionality change.

llvm-svn: 65563

Fix <rdar://problem/6574319> clang issues error on 'readonly' property with a defaul setter attribute.

Needed to make isPropertyReadonly() non-const (for this fix to compile). I imagine there's a way to retain the const-ness, however I have more important fish to fry.

llvm-svn: 65562

libtool doesn't exist.

llvm-svn: 65561

 - No functionality change.

llvm-svn: 65560

llvm-svn: 65559

llvm-svn: 65558

llvm-svn: 65557

llvm-svn: 65554

llvm-svn: 65553

llvm-svn: 65552

1662184 bytes (~10%)

llvm-svn: 65551

the symbol for the root meta-data.

llvm-svn: 65548

This was a fairly recent regression.

llvm-svn: 65547

llvm-svn: 65544

llvm-svn: 65543

substantially happier on some versions of Mac OS/X.

llvm-svn: 65542

llvm-svn: 65540