Submitted by:
Reviewed by:
Refactored ParseNumericConstant using SkipDigits and friends. This
cleaned up the code and removed many "breaks". In the process, I found
several bugs that needed to be fixed (proof that this refactoring had
real value, not simply aesthetics). Also simplified error handling logic
and removed an unused error condition from Diagnostics.def.
llvm-svn: 39350
Submitted by:
Reviewed by:
More code to parse numeric constants. This checkin includes:
- Feedback from Chris.
- Support for parsing floating point constants.
- Moved the code to "Sema". Changed API in Action.
- More/better error diagnostics.
At this point, the parsing support should be largely complete. Next step
is to work on filling in sensible values (in IntegerLiteral/FloatLiteral).
llvm-svn: 39349
Submitted by:
Reviewed by:
First phase of parsing IntegerConstants. At the moment, all processing
is done in the Parser, not Sema. If necessary, this is easy to move.
Next steps:
- Convert well for strings to actual values (need to look @ APInt.h)
- Design the API between the Parser and Sema. Sema shouldn't have to be
concerned with any parsing issues...
llvm-svn: 39348
it to Sema/ASTStreamer (separating the lifetime of ASTContext from
the lifetime of Sema). One day it might be useful to consider creating
a context object implicitly if one isn't provided (using default arguments in
Sema's constructor). At this point, adding this convenience isn't necessary.
llvm-svn: 39346
the prerocessor will be available via ASTContext).
- Removed the public data member "PP" in ASTContext.
- Changed ASTContext's contructor to take TargetInfo/IdentifierTable explicitly.
- Implicitly create an ASTContext in Sema's constructor. This simplifies
the clients job (and makes ASTContext more private).
--As a side effect, added a "PrintStats" hook to Sema.
To support this level of encapsulation, ASTContext is always dynamically
allocated (by Sema). Previously, ASTContext was being allocated on the
stack. I don't believe this should be a performance issue (since ASTContext
is fairly course grain and tied to the lifetime of Sema currently).
llvm-svn: 39345
This set of changes includes:
- convert ExprCXX.h and add to the Xcode project file.
-- required adding CXXBoolLiteralExpr to StmtNodes.def.
-- required adding visitor support (decl/defn).
- make the class codes in StmtNodes.def explicit (to enable range checking).
-- this required changing all clients of the STMT macro.
- declare the instance data const.
llvm-svn: 39344
- adding enum constants & instance data to Stmt.
- adding classof() functions to all Stmt's.
- modifying contructors to pass the appropriate enum as an arg.
Also tightened up a couple "void *" declarations/casts for arrays.
llvm-svn: 39343
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
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
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
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
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
"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
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
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
This emits these diagnostics:
t.c:4:14: error: redefinition of 'a'
enum foo22 { a, b };
^
t.c:3:5: error: previous definition is here
int a;
^
t.c:8:17: error: redefinition of enumerator 'b'
enum foo23 { c, b };
^
t.c:4:17: error: previous definition is here
enum foo22 { a, b };
^
4 diagnostics generated.
for:
int a;
enum foo22 { a, b };
enum foo23 { c, b };
llvm-svn: 39302