clang still compiled/linked/ran properly...simply a confusing name regression.
From now on I'll make sure I run "cvs diff" before committing any changes!

llvm-svn: 39342

rename FloatingConstant->FloatingLiteral
rename StringExpr->StringLiteral

llvm-svn: 39341

llvm-svn: 39340

llvm-svn: 39339

llvm-svn: 39338

llvm-svn: 39337

llvm-svn: 39336

llvm-svn: 39335

llvm-svn: 39334

llvm-svn: 39333

llvm-svn: 39332

llvm-svn: 39331

llvm-svn: 39330

carbon.h on intel, bringing the total to 257.

llvm-svn: 39329

of source code.  For example:

$ clang INPUTS/carbon_h.c -arch i386 -arch ppc
prints:
...
/usr/lib/gcc/i686-apple-darwin8/4.0.1/include/mmintrin.h:51:3: note: use of a target-specific builtin function, source is not 'portable'
  __builtin_ia32_emms ();
  ^

because carbon.h pulls in xmmintrin.h, and __builtin_ia32_emms isn't a builtin on ppc.

Though clang now supports target-specific builtins, the full table isn't implemented yet.

llvm-svn: 39328

whose decl objects are lazily created the first time they are referenced.
Builtin functions are described by the clang/AST/Builtins.def file, which
makes it easy to add new ones.

This is missing two important pieces:
1. Support for the rest of the gcc builtins.
2. Support for target-specific builtins (e.g. __builtin_ia32_emms).

Just adding this builtins reduces the number of implicit function definitions
by 6, reducing the # diagnostics from 550 to 544 when parsing carbon.h.

I need to add all the i386-specific ones to eliminate several hundred more.
ugh.

llvm-svn: 39327

llvm-svn: 39326

translation-unit scope, so we only warn about each implicitly defined
function once.  This cuts the number of errors parsing carbon.h from 616 to 550.

llvm-svn: 39325

proto, then a function body, and they have the same type, don't emit an error.
This reduces #errors from 654->616

llvm-svn: 39324

int foo;
int foo();

llvm-svn: 39323

llvm-svn: 39322

actually add it into the declspec for the type being parsed.  This allows us
to do correct semantic analysis on:

typedef int bar;
int foo() {
  bar a;
  return a;
}

This reduces # errors parsing carbon.h from 731 to 654.

llvm-svn: 39321

use the folding set.  This eliminates 359 slow lookups from carbon.h (the
rest) but doesn't substantially speed up parse.

llvm-svn: 39320

search.  This reduces 'dumb' lookups from 1225 to 359, speeding up parse
of carbon.h from 0.173 to 0.156s (10%).

llvm-svn: 39319

llvm-svn: 39318

SmallPtrSet data structure.  This datastructure handles the 'nonsmall' case
quite gracefully, with an efficient exponentially probed hashtable.  This is
important for handling global scope, which gets many thousands of decls (e.g.
every function and enum value).  Of course the typical inner scopes are still
as efficient as ever.

On my mac pro, this speeds up parsing carbon.h from 0.59s to 0.168s (3.5x),
and there is still low hanging fruit :).

For reference, GCC on the same system takes 0.33s for -fsyntax-only.

llvm-svn: 39317

llvm-svn: 39316

llvm-svn: 39315

llvm-svn: 39314

llvm-svn: 39313

"obviously braindead" linear searches.  reduces the number of slow
type lookups from 10K to 883 on carbon.h, speeding up parsing from 3.5 to
1.26s.

llvm-svn: 39312

a foldingset instead.  This reduces the number of slow type lookups from
32K to 10K, which speeds up parsing of carbon.h from 11s to 3.5s.

llvm-svn: 39311

llvm-svn: 39310

llvm-svn: 39309

This speeds up parsing carbon.h from 16.0s to 11.3s, reducing slow
lookups from 63K to 32K.

llvm-svn: 39308

llvm-svn: 39307

ASTContext::getTagDeclType by not having to do a linear search.  With this,
parse time for carbon.h drops from 21.8s to 16.0s and # slow lookups drop from
83K to 63K.

llvm-svn: 39306

*** AST Context Stats:
  30594 types total.
    19 builtin types
    3929 pointer types
    308 array types
    18883 function types with proto
    8 function types with no proto
    2988 typename (typedef) types
    4459 tagged types
      1476 struct types
      80 union types
      0 class types
      2903 enum types
  83298 slow type lookups

Next up, making type canonicalization not trivially silly.

llvm-svn: 39305

llvm-svn: 39304

struct q { int a, a; };

with:

t.c:3:19: error: duplicate member 'a'
struct q { int a, a; };
                  ^
t.c:3:16: error: previous definition is here
struct q { int a, a; };
               ^

llvm-svn: 39303