Daniel Dunbar [Mon, 5 Jan 2009 22:14:37 +0000 (22:14 +0000)]
Implement getFloatingRank() for extended vectors.
- I'm not sure this is appropriate, but it seems reasonable to be
able to call getFloatingRank on anything which isFloatingType().
Sebastian Redl [Mon, 5 Jan 2009 20:52:13 +0000 (20:52 +0000)]
PODness and Type Traits
Make C++ classes track the POD property (C++ [class]p4)
Track the existence of a copy assignment operator.
Implicitly declare the copy assignment operator if none is provided.
Implement most of the parsing job for the G++ type traits extension.
Fully implement the low-hanging fruit of the type traits:
__is_pod: Whether a type is a POD.
__is_class: Whether a type is a (non-union) class.
__is_union: Whether a type is a union.
__is_enum: Whether a type is an enum.
__is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1).
Daniel Dunbar [Mon, 5 Jan 2009 19:53:30 +0000 (19:53 +0000)]
Add prototype ccc rewrite.
- Entry point is tools/ccc/xcc until we are a functional replacement
for ccc.
This is highly experimental (FIXME/LOC ratio of 3.4%), quite crufty,
and barely usable (and then only on my specific Darwin). However, many
of the right ideas are present, and it already fixes a number of
things gcc gets wrong.
The major missing component is argument translation for tools
(translating driver arguments into cc1/ld/as/etc. arguments). This is
a large part of the driver functionality and will probably double the
LOC, but my hope is that the current architecture is relatively
stable.
Douglas Gregor [Mon, 5 Jan 2009 19:45:36 +0000 (19:45 +0000)]
Introduce support for "transparent" DeclContexts, which are
DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.
Only enumerations and linkage specifications currently use transparent
DeclContexts.
Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.
Chris Lattner [Mon, 5 Jan 2009 01:24:05 +0000 (01:24 +0000)]
TryAnnotateTypeOrScopeToken and TryAnnotateCXXScopeToken can
only be called when they might be needed now, so make them assert
that their current token is :: or identifier.
Chris Lattner [Mon, 5 Jan 2009 00:13:00 +0000 (00:13 +0000)]
ParseCXXSimpleTypeSpecifier can only be called on things that are
verified to be simple type specifiers, so there is no need for it
to call TryAnnotateTypeOrScopeToken.
Make MaybeParseCXXScopeSpecifier reject ::new and ::delete with a
hard error now that it may never be transitively called in a
context where these are legal. This allows me to start
disentangling things more.
Chris Lattner [Sun, 4 Jan 2009 23:51:17 +0000 (23:51 +0000)]
Simplify some control flow and remove a call to TryAnnotateCXXScopeToken
that isn't doing what is desired. It was annotating the current token
not the 'next' token. This code should be fixed.
Chris Lattner [Sun, 4 Jan 2009 23:33:56 +0000 (23:33 +0000)]
push the call in isCXXDeclarationSpecifier to TryAnnotateTypeOrScopeToken
down into the two cases that it can possibly affect. This avoids calls
to it that obviously can't do anything.
Chris Lattner [Sun, 4 Jan 2009 23:23:14 +0000 (23:23 +0000)]
my previous patch caused sema to drop the global qualifier, make
sure to pass it down. This makes the code a bit gross, I will clean
it up in subsequent commits.
Chris Lattner [Sun, 4 Jan 2009 22:52:14 +0000 (22:52 +0000)]
sink the call to TryAnnotateTypeOrScopeToken in
ParseCastExpression into the switch. This gets it out of the hot
path through ParseCastExpression for all the non-identifier and
non-:: tokens.
Anders Carlsson [Sun, 4 Jan 2009 02:08:04 +0000 (02:08 +0000)]
Fix the bug that would cause Python to crash at startup.
When emitting the static variables we need to make sure that the order is preserved.
Fix this by making StaticDecls a std::list which has O(1) random removal.
Steve Naroff [Wed, 24 Dec 2008 20:59:21 +0000 (20:59 +0000)]
Add explicit "fuzzy" parse support for Microsoft declspec.
Remove previous __declspec macro that would effectively erase the construct prior to parsing.
Douglas Gregor [Wed, 24 Dec 2008 02:52:09 +0000 (02:52 +0000)]
Keep track of template arguments when we parse them. Right now, we don't actually do anything with the template arguments, but they'll be used to create template declarations
Douglas Gregor [Wed, 24 Dec 2008 00:01:03 +0000 (00:01 +0000)]
Correct the order in which we cope with end-of-class-definition
semantics and improve our handling of default arguments. Specifically,
we follow this order:
- As soon as the see the '}' in the class definition, the class is
complete and we add any implicit declarations (default constructor,
copy constructor, etc.) to the class.
- If there are any default function arguments, parse them
- If there were any inline member function definitions, parse them
As part of this change, we now keep track of the the fact that we've
seen unparsed default function arguments within the AST. See the new
ParmVarDecl::hasUnparsedDefaultArg member. This allows us to properly
cope with calls inside default function arguments to other functions
where we're making use of the default arguments.
Made some C++ error messages regarding failed initializations more
specific.
Douglas Gregor [Tue, 23 Dec 2008 21:31:30 +0000 (21:31 +0000)]
When determining whether a class type has a const copy constructor, be
sure to look at all of the results returned by name lookup. Fixes
<rdar://problem/6465262>
Douglas Gregor [Tue, 23 Dec 2008 21:05:05 +0000 (21:05 +0000)]
Don't push OverloadedFunctionDecls onto the chain of declarations
attached to an identifier. Instead, all overloaded functions will be
pushed into scope, and we'll synthesize an OverloadedFunctionDecl on
the fly when we need it.
Ted Kremenek [Tue, 23 Dec 2008 18:41:34 +0000 (18:41 +0000)]
PTH: Use 3 bytes instead of 4 bytes to encode the persistent ID for a token.
- This reduces the PTH size for Cocoa.h by 7%.
- The increases PTH -Eonly speed for Cocoa.h by 0.8%.
Ted Kremenek [Tue, 23 Dec 2008 02:52:12 +0000 (02:52 +0000)]
PTH:
- Encode the token length with 2 bytes instead of 4.
- This reduces the size of the .pth file for Cocoa.h by 12%.
- This speeds up PTH time (-Eonly) on Cocoa.h by 1.6%.
Ted Kremenek [Tue, 23 Dec 2008 02:30:15 +0000 (02:30 +0000)]
PTH:
- In PTHLexer::Lex read all of the token data from PTH file before
constructing the token. The idea is to enhance locality.
- Do not use Read8/Read32 in PTHLexer::Lex. Inline these operations manually.
- Change PTHManager::ReadIdentifierInfo() to PTHManager::GetIdentifierInfo().
They are functionally the same except that PTHLexer::Lex() reads the
persistent id.
These changes result in a 3.3% speedup for PTH on Cocoa.h (-Eonly).
Ted Kremenek [Tue, 23 Dec 2008 01:30:52 +0000 (01:30 +0000)]
PTH:
- Embed 'eom' tokens in PTH file.
- Use embedded 'eom' tokens to not lazily generate them in the PTHLexer.
This means that PTHLexer can always advance to the next token after
reading a token (instead of buffering tokens using a copy).
- Moved logic of 'ReadToken' into Lex. GetToken & ReadToken no longer exist.
- These changes result in a 3.3% speedup (-Eonly) on Cocoa.h.
- The code is a little gross. Many cleanups are possible and should be done.
Douglas Gregor [Tue, 23 Dec 2008 00:26:44 +0000 (00:26 +0000)]
Don't explicitly represent OverloadedFunctionDecls within
DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.
This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.
Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.