and uninitialized use options.

llvm-svn: 62270

llvm-svn: 62268

llvm-svn: 62261

llvm-svn: 62255

 - Mostly written as an entertaining exercise in enumerating large or
   (countably, naturally) infinite sets. But hey, its useful too!

 - Idea is to number all C-types so that the N-th type can quickly be
   computed, with a good deal of flexibility about what types to
   include, and taking some care so that the (N+1)-th type is
   interestingly different from the N-th type. For example, using the
   default generator, the 1,000,000-th function type is:
--
typedef _Complex int T0;
typedef char T1 __attribute__ ((vector_size (4)));
typedef int T2 __attribute__ ((vector_size (4)));
T2 fn1000000(T0 arg0, signed long long arg1, T1 arg2, T0 arg3);
--
   and the 1,000,001-th type is:
--
typedef _Complex char T0;
typedef _Complex char T2;
typedef struct T1 { T2 field0; T2 field1; T2 field2; } T1;
typedef struct T3 {  } T3;
unsigned short fn1000001(T0 arg0, T1 arg1, T3 arg2);
--

   Computing the 10^1600-th type takes a little less than 1s. :)

llvm-svn: 62253

llvm-svn: 62250

lexical order of the corresponding identifier strings. This will be used for a
forthcoming optimization. This slows down PTH generation time by 7%. We can
revert this change if the optimization proves to not be valuable.

llvm-svn: 62248

llvm-svn: 62247

This requires some hackery, as gcc's PCH mechanism changes behavior,
whereas while PTH is simply a cache. Notably:

 - Automatically cause clang to load a .pth file if we find one that
   matches a command line -include argument (similar to how gcc
   looks for .gch files).

 - When generating precompiled headers, translate the suffix from .gch
   to .pth (so we do not conflict with actual gcc PCH files).

 - When generating precompiled headers, copy the input header to the
   same location as the output PTH file. This is necessary because gcc
   supports -include xxx.h even if xxx.h doesn't exist, but for clang
   we need to actually have the contents of this file available.

llvm-svn: 62246

This change refactors and cleans up our handling of name lookup with
LookupDecl. There are several aspects to this refactoring:

  - The criteria for name lookup is now encapsulated into the class
  LookupCriteria, which replaces the hideous set of boolean values
  that LookupDecl currently has.

  - The results of name lookup are returned in a new class
  LookupResult, which can lazily build OverloadedFunctionDecls for
  overloaded function sets (and, eventually, eliminate the need to
  allocate member for OverloadedFunctionDecls) and contains a
  placeholder for handling ambiguous name lookup (for C++).

  - The primary entry points for name lookup are now LookupName (for
    unqualified name lookup) and LookupQualifiedName (for qualified
    name lookup). There is also a convenience function
    LookupParsedName that handles qualified/unqualified name lookup
    when given a scope specifier. Together, these routines are meant
    to gradually replace the kludgy LookupDecl, but this won't happen
    until after we have base class lookup (which forces us to cope
    with ambiguities).

  - Documented the heck out of name lookup. Experimenting a little
    with using Doxygen's member groups to make some sense of the Sema
    class. Feedback welcome!

  - Fixes some lingering issues with name lookup for
  nested-name-specifiers, which now goes through
  LookupName/LookupQualifiedName. 

llvm-svn: 62245

(DRIVER_[AB]).

llvm-svn: 62242

 - Still missing some odds and ends like -M.

 - Also, we still need to do some translation and forwarding of
   codegen options.

llvm-svn: 62241

explicit return type on block literals.

llvm-svn: 62240

llvm-svn: 62239

llvm-svn: 62237

Small cleanup in the handling of user-defined conversions. 

Also, implement an optimization when constructing a call. We avoid
recomputing implicit conversion sequences and instead use those
conversion sequences that we computed as part of overload resolution.

llvm-svn: 62231

llvm-svn: 62214

llvm-svn: 62213

 - This is what ccc (old) currently handles.

 - Clang accepts some more things that aren't getting forwarded...

llvm-svn: 62210

 - hello.cpp is XFAIL pending g++ emulation.

llvm-svn: 62208

CCC_ECHO, and CCC_FALLBACK from environment as ccc (old) did.

llvm-svn: 62207

llvm-svn: 62206

llvm-svn: 62205

llvm-svn: 62204

FunctionDecl::setParams() now uses the allocator associated with ASTContext to allocate the array of ParmVarDecl*'s.

llvm-svn: 62203

llvm-svn: 62200

objects as an objective-c object.

llvm-svn: 62197

- Use canonical FileID when using getSpelling() caching.  This
  addresses some cache misses we were seeing with -fsyntax-only on
  Cocoa.h
- Added Preprocessor::getPhysicalCharacterAt() utility method for
  clients to grab the first character at a specified sourcelocation.
  This uses the PTH spelling cache.
- Modified Sema::ActOnNumericConstant() to use
  Preprocessor::getPhysicalCharacterAt() instead of
  SourceManager::getCharacterData() (to get PTH hits).

These changes cause -fsyntax-only to not page in any sources from
Cocoa.h.  We see a speedup of 27%.

llvm-svn: 62193

llvm-svn: 62192

llvm-svn: 62187

PTH: Fix remaining cases where the spelling cache in the PTH file was being missed when it shouldn't.  This shaves another 7% off PTH time for -Eonly on Cocoa.h

llvm-svn: 62186

llvm-svn: 62183

llvm-svn: 62182

for the Darwin tool chain.
 - Ideally we would localize these to tool specific argument
   processing but for now this matches gcc closely.

llvm-svn: 62181

Turn off some Destroy calls that are currenly causing double-destruction of ScopedDecls. We will re-enable this later, when we have time to fully solve the ownership issue.

llvm-svn: 62175

 - Pulled -Xarch processing into this.

 - Get rid of manual creation of forwarding arg array.

 - Use Darwin/CC1 instead of generic GCC cc1 on X86.

llvm-svn: 62172

llvm-svn: 62170

DeclContext::KindTrait was not meant to be used outside of DeclContext::CastTo (causes compilation error on MSVC).
Add DeclContext::getDeclKind() and use that instead of DeclContext::KindTrait.

llvm-svn: 62164

llvm-svn: 62157

support -###.

llvm-svn: 62156