llvm-svn: 84415

llvm-svn: 84414

llvm-svn: 84413

TemplateTypeParmType with the substituted type directly;  instead, replace it
with a SubstTemplateTypeParmType which will note that the type was originally
written as a template type parameter.  This makes it reasonable to preserve
source information even through template substitution.

Also define the new SubstTemplateTypeParmType class, obviously.

For consistency with current behavior, we stringize these types as if they
were the underlying type.  I'm not sure this is the right thing to do.
At any rate, I paled at adding yet another clause to the don't-desugar 'if'
statement, so I extracted a function to do it.  The new function also does
The Right Thing more often, I think:  e.g. if we have a chain of typedefs
leading to a vector type, we will now desugar all but the last one.

llvm-svn: 84412

llvm-svn: 84398

llvm-svn: 84394

llvm-svn: 84393

 - Really this should be simplified by the FIXME above, but I'm too deep in DFS.

llvm-svn: 84392

llvm-svn: 84391

 - I have this crazy dream that one day someone will invent a miraculous tool so
   that developers, instead of hand optimizing their source code to obscure its
   intent and decrease its maleability, will instead write what they mean, and
   this strange and wonderful tool -- which I imagine would be called something
   fancy sounding like "an optimizing compiler" -- will make their code fast
   *for* them. With all the saved time, developers could maybe even focus on
   making the magic "optimizing compiler" better!!

 - No intended functionality change, all though I expect the universe to mock me
   for snarkiness.

llvm-svn: 84390

llvm-svn: 84389

llvm-svn: 84388

TypeLoc class names to be $(Type classname)Loc.  Rewrite the visitor.
Provide skeleton implementations for all the new TypeLocs.

Handle all cases in PCH.  Handle a few more cases when inserting
location information in SemaType.

It should be extremely straightforward to add new location information
to existing TypeLoc objects now.

llvm-svn: 84386

llvm-svn: 84381

llvm-svn: 84380

llvm-svn: 84379

llvm-svn: 84378

llvm-svn: 84377

llvm-svn: 84376

llvm-svn: 84375

llvm-svn: 84371

llvm-svn: 84370

llvm-svn: 84369

llvm-svn: 84366

initialization if any of the constructor/initialization arguments are
type-dependent. Fixes PR5224.

llvm-svn: 84365

When resolving the address of an overloaded function or function template, mark the result as referenced.

The most important effect of this is that function templates only referenced by address expressions now get instantiated. This, in turn, means that Hello World compiles with the Apache stdcxx library even when using endl.

llvm-svn: 84363

Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case.

llvm-svn: 84362

llvm-svn: 84361

llvm-svn: 84360

llvm-svn: 84359

llvm-svn: 84354

fixing PR4838.

llvm-svn: 84353

In some dependent contexts, incomplete array types persist into FinalizeDeclaratorGroup. Don't require them to have a complete type. This allows us to compile Hello World with the Apache stdcxx library. If you don't use endl, it even links and runs.

llvm-svn: 84347

llvm-svn: 84346

llvm-svn: 84345

llvm-svn: 84343

llvm-svn: 84342

llvm-svn: 84341

llvm-svn: 84340

llvm-svn: 84339