summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* cleanupChris Lattner2009-02-271-4/+4
| | | | llvm-svn: 65646
* Implementing parsing of template-ids as class-names, so that we canDouglas Gregor2009-02-251-1/+2
| | | | | | | | derive from a class template specialization, e.g., class B : public A<int> { }; llvm-svn: 65488
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-27/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* Update Parser::ParseTypeName to return a TypeResult, which also tellsDouglas Gregor2009-02-181-9/+22
| | | | | | | | us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
* Allow "overloadable" functions in C to be declared as variadic withoutDouglas Gregor2009-02-181-10/+5
| | | | | | | | | | | | | | | any named parameters, e.g., this is accepted in C: void f(...) __attribute__((overloadable)); although this would be rejected: void f(...); To do this, moved the checking of the "ellipsis without any named arguments" condition from the parser into Sema (where it belongs anyway). llvm-svn: 64902
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-2/+2
| | | | | | | | | | | | | | | | | | specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-091-3/+19
| | | | | | | | | | | | | | | | | | | | | to a class template. For example, the template-id 'vector<int>' now has a nice, sugary type in the type system. What we can do now: - Parse template-ids like 'vector<int>' (where 'vector' names a class template) and form proper types for them in the type system. - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly, using (sadly) a bool in the parser to tell it whether '>' should be treated as an operator or not. This is a baby-step, with major problems and limitations: - There are currently two ways that we handle template arguments (whether they are types or expressions). These will be merged, and, most likely, TemplateArg will disappear. - We don't have any notion of the declaration of class template specializations or of template instantiations, so all template-ids are fancy names for 'int' :) llvm-svn: 64153
* Implement Declarator::getSourceRange().Sebastian Redl2009-02-091-56/+102
| | | | llvm-svn: 64151
* Make Sema::getTypeName return the opaque pointer of a QualType ratherDouglas Gregor2009-02-091-4/+4
| | | | | | | | | | | | | | | | than a Decl, which gives us some more flexibility to express the results with the type system. There are no clients using this flexibility yet, but it's meant to be able to describe qualified names as written in the source (e.g., "foo::type") or template-ids that name a class template specialization (e.g., "std::vector<INT>"). DeclSpec's TST_typedef has become TST_typename, to reflect its use to describe types found by name (that may or may not be typedefs). The type representation of a DeclSpec with TST_typename is an opaque QualType pointer. All users of TST_typedef, both direct and indirect, have been updated for these changes. llvm-svn: 64141
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-2/+1
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Put the invalid flag of OwningResult into the Action pointer.Sebastian Redl2009-02-051-1/+1
| | | | | | | | This shrinks OwningResult by one pointer. Since it is no longer larger than OwningPtr, merge the two. This leads to simpler client code and speeds up my benchmark by 2.7%. For some reason, this exposes a previously hidden bug, causing a regression in SemaCXX/condition.cpp. llvm-svn: 63867
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-041-1/+1
| | | | llvm-svn: 63750
* Diagnose ambiguities in getTypeName. Fixes ↵Douglas Gregor2009-02-041-5/+7
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=3475 llvm-svn: 63737
* Simplify/cleanup r63219 (based on Chris review).Steve Naroff2009-01-301-13/+1
| | | | llvm-svn: 63393
* move library-specific diagnostic headers into library private dirs. ReduceChris Lattner2009-01-291-1/+1
| | | | | | redundant #includes. Patch by Anders Johnsen! llvm-svn: 63271
* Name change (isTypeName->getTypeName).Steve Naroff2009-01-281-7/+7
| | | | | | Since it doesn't return a bool, is shouldn't be prefixed with 'is'. llvm-svn: 63226
* Change Parser::ParseFunctionDeclarator() to annotate typename tokens.Steve Naroff2009-01-281-9/+21
| | | | | | This removes ~10% of the calls to Sema::isTypeName(), which amount to a little less than a 1% reduction in usertime (for Cocoa.h). llvm-svn: 63219
* Split the single monolithic DiagnosticKinds.def file into oneChris Lattner2009-01-271-1/+1
| | | | | | | | | .def file for each library. This means that adding a diagnostic to sema doesn't require all the other libraries to be rebuilt. Patch by Anders Johnsen! llvm-svn: 63111
* Some micro-optimizations for DISABLE_SMART_POINTERS:Douglas Gregor2009-01-261-1/+1
| | | | | | | | | | | | | | | | | - When it's safe, ActionResult uses the low bit of the pointer for the "invalid" flag rather than a separate "bool" value. This keeps GCC from generating some truly awful code, for a > 3x speedup in the result-passing microbenchmark. - When DISABLE_SMART_POINTERS is defined, store an ActionResult within ASTOwningResult rather than an ASTOwningPtr. Brings the performance benefits of the above to smart pointers with DISABLE_SMART_POINTERS defined. Sadly, these micro-benchmark performance improvements don't seem to make much of a difference on Cocoa.h right now. However, they're harmless and might help with future optimizations. llvm-svn: 63061
* Add support for declaring pointers to members.Sebastian Redl2009-01-241-10/+42
| | | | | | Add serialization support for ReferenceType. llvm-svn: 62934
* Inline ParseOptionalTypeSpecifier into ParseDeclarationSpecifiers. Chris Lattner2009-01-211-9/+108
| | | | | | | This avoids call overhead and extraneous switches when parsing very simple declspecs like "int" "void" etc, which are pretty common :) llvm-svn: 62711
* ParseOptionalTypeSpecifier should consume a token if it returns true.Chris Lattner2009-01-211-4/+5
| | | | llvm-svn: 62704
* Optimize Declarator to avoid malloc/free traffic for the argument list of aChris Lattner2009-01-201-3/+3
| | | | | | | | | | | | | | | | function DeclaratorChunk in common cases. This uses a fixed array in Declarator when it is small enough for the first function declarator chunk in a declarator. This eliminates all malloc/free traffic from DeclaratorChunk::getFunction when running on Cocoa.h except for five functions: signal/bsd_signal/sigset, which have multiple Function DeclChunk's, and CFUUIDCreateWithBytes/CFUUIDGetConstantUUIDWithBytes, which take more than 16 arguments. This patch was pair programmed with Steve. llvm-svn: 62599
* Convert a few expression actions to smart pointers.Sebastian Redl2009-01-181-1/+1
| | | | | | These actions are extremely widely used (identifier expressions and literals); still no performance regression. llvm-svn: 62468
* Rename move_convert to move_arg and move_res. The new names are less ↵Sebastian Redl2009-01-181-1/+1
| | | | | | misleading (and shorter). llvm-svn: 62466
* Catch a foreach parse error.Fariborz Jahanian2009-01-171-0/+5
| | | | llvm-svn: 62382
* Implement support for anonymous structs and unions in C. Both C andDouglas Gregor2009-01-121-2/+3
| | | | | | | | | | | | | | C++ handle anonymous structs/unions in the same way. Addresses several bugs: <rdar://problem/6259534> <rdar://problem/6481130> <rdar://problem/6483159> The test case in PR clang/1750 now passes with -fsyntax-only, but CodeGen for inline assembler still fails. llvm-svn: 62112
* Allow multiple Microsoft calling-convention keywords. Fixes ↵Douglas Gregor2009-01-101-2/+2
| | | | | | rdar://problem/6486133 llvm-svn: 62018
* When we see a reference to a struct, class, or union like "struct X"Douglas Gregor2009-01-091-3/+3
| | | | | | | | | | | | | | | | that is neither a definition nor a forward declaration and where X has not yet been declared as a tag, introduce a declaration into the appropriate scope (which is likely *not* to be the current scope). The rules for the placement of the declaration differ slightly in C and C++, so we implement both and test the various corner cases. This implementation isn't 100% correct due to some lingering issues with the function prototype scope (for a function parameter list) not being the same scope as the scope of the function definition. Testcase is FIXME'd; this probably isn't an important issue. Addresses <rdar://problem/6484805>. llvm-svn: 62014
* Unify the code for defining tags in C and C++, so that we alwaysDouglas Gregor2009-01-081-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduce a Scope for the body of a tag. This reduces the number of semantic differences between C and C++ structs and unions, and will help with other features (e.g., anonymous unions) in C. Some important points: - Fields are now in the "member" namespace (IDNS_Member), to keep them separate from tags and ordinary names in C. See the new test in Sema/member-reference.c for an example of why this matters. In C++, ordinary and member name lookup will find members in both the ordinary and member namespace, so the difference between IDNS_Member and IDNS_Ordinary is erased by Sema::LookupDecl (but only in C++!). - We always introduce a Scope and push a DeclContext when we're defining a tag, in both C and C++. Previously, we had different actions and different Scope/CurContext behavior for enums, C structs/unions, and C++ structs/unions/classes. Now, it's one pair of actions. (Yay!) There's still some fuzziness in the handling of struct/union/enum definitions within other struct/union/enum definitions in C. We'll need to do some more cleanup to eliminate some reliance on CurContext before we can solve this issue for real. What we want is for something like this: struct X { struct T { int x; } t; }; to introduce T into translation unit scope (placing it at the appropriate point in the IdentifierResolver chain, too), but it should still have struct X as its lexical declaration context. PushOnScopeChains isn't smart enough to do that yet, though, so there's a FIXME test in nested-redef.c llvm-svn: 61940
* Another tweak to handle the MS extensions (<rdar://problem/5956221>).Steve Naroff2009-01-061-0/+1
| | | | llvm-svn: 61821
* rename MaybeParseCXXScopeSpecifier -> ParseOptionalCXXScopeSpecifier and Chris Lattner2009-01-061-9/+9
| | | | | | MaybeParseTypeSpecifier -> ParseOptionalTypeSpecifier. llvm-svn: 61796
* rename tok::annot_qualtypename -> tok::annot_typename, which is bothChris Lattner2009-01-061-3/+3
| | | | | | shorter and more accurate. The type name might not be qualified. llvm-svn: 61788
* Introduce support for "transparent" DeclContexts, which areDouglas Gregor2009-01-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 61735
* sink a call to TryAnnotateCXXScopeToken down into theChris Lattner2009-01-051-9/+14
| | | | | | applicable cases in ParseDeclarationSpecifiers. llvm-svn: 61657
* sink calls to TryAnnotateTypeOrScopeToken down into the only cases that they Chris Lattner2009-01-041-9/+59
| | | | | | can interact with. llvm-svn: 61652
* Parser support for C++ using directives, from Piotr RakDouglas Gregor2008-12-301-0/+4
| | | | llvm-svn: 61486
* Add support for out-of-line definitions of conversion functions and member ↵Douglas Gregor2008-12-261-21/+16
| | | | | | operators llvm-svn: 61442
* Add parser support for __forceinline, __w64, __ptr64.Steve Naroff2008-12-251-0/+3
| | | | llvm-svn: 61431
* Add parser support for __cdecl, __stdcall, and __fastcall.Steve Naroff2008-12-251-0/+36
| | | | | | Change preprocessor implementation of _cdecl to reference __cdecl. llvm-svn: 61430
* Add explicit "fuzzy" parse support for Microsoft declspec.Steve Naroff2008-12-241-0/+21
| | | | | | Remove previous __declspec macro that would effectively erase the construct prior to parsing. llvm-svn: 61422
* Keep track of template arguments when we parse them. Right now, we don't ↵Douglas Gregor2008-12-241-5/+8
| | | | | | actually do anything with the template arguments, but they'll be used to create template declarations llvm-svn: 61413
* Correct the order in which we cope with end-of-class-definitionDouglas Gregor2008-12-241-2/+6
| | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 61406
* Ultrasimplistic sketch for the parsing of C++ template-ids. This won'tDouglas Gregor2008-12-181-4/+18
| | | | | | | | become useful or correct until we (1) parse template arguments correctly, (2) have some way to turn template-ids into types, declarators, etc., and (3) have a real representation of templates. llvm-svn: 61208
* add a simple fast-path for the common case of [] and [4] in Chris Lattner2008-12-181-1/+32
| | | | | | | | array size declarators. No need to go through all the trouble of parsing crazy things like [static const 4] when most code doesn't need it. llvm-svn: 61200
* disallow attributes in a few callers of ParseTypeQualifierListOpt,Chris Lattner2008-12-181-13/+16
| | | | | | | these completely ignore parsed attributes anyway, so don't try to read them. llvm-svn: 61198
* Clean up the C89/C++ warnings about C99 array features to not Chris Lattner2008-12-181-12/+5
| | | | | | | | emit duplicate diags (some in parser and some in sema) and to warn about use of typequals in array sizes. This implements PR2759. llvm-svn: 61197
* Delay parsing of default arguments of member functions until the classDouglas Gregor2008-12-161-12/+31
| | | | | | | | | | is completely defined (C++ [class.mem]p2). Reverse the order in which we process the definitions of member functions specified inline. This way, we'll get diagnostics in the order in which the member functions were declared in the class. llvm-svn: 61103
* Some utilities for using the smart pointers in Actions, especially Sema. ↵Sebastian Redl2008-12-131-1/+1
| | | | | | Convert a few functions. llvm-svn: 60983
* Convert a big bunch of expression parsers to use smart pointers.Sebastian Redl2008-12-111-1/+1
| | | | llvm-svn: 60906
OpenPOWER on IntegriCloud