summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTReaderDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* When determining whether we can make a declaration into a globalDouglas Gregor2011-05-131-0/+1
| | | | | | | constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
* Implement defaulting of destructors.Alexis Hunt2011-05-121-0/+2
| | | | llvm-svn: 131260
* Implement implicit deletion of default constructors.Alexis Hunt2011-05-111-1/+1
| | | | | | | | Yes, I'm aware that the diagnostics are awful. Tests to follow. llvm-svn: 131203
* Clean up trivial default constructors now.Alexis Hunt2011-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | hasTrivialDefaultConstructor() really really means it now. Also implement a fun standards bug regarding aggregates. Doug, if you'd like, I can un-implement that bug if you think it is truly a defect. The bug is that non-special-member constructors are never considered user-provided, so the following is an aggregate: struct foo { foo(int); }; It's kind of bad, but the solution isn't obvious - should struct foo { foo (int) = delete; }; be an aggregate or not? Lastly, add a missing initialization to FunctionDecl. llvm-svn: 131101
* Rename "hasTrivialConstructor" to "hasTrivialDefaultConstructor" andAlexis Hunt2011-05-091-1/+1
| | | | | | | modify the semantics slightly to accomodate default constructors (I hope). llvm-svn: 131087
* Modify some deleted function methods to better reflect reality:Alexis Hunt2011-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | - New isDefined() function checks for deletedness - isThisDeclarationADefinition checks for deletedness - New doesThisDeclarationHaveABody() does what isThisDeclarationADefinition() used to do - The IsDeleted bit is not propagated across redeclarations - isDeleted() now checks the canoncial declaration - New isDeletedAsWritten() does what it says on the tin. - isUserProvided() now correct (thanks Richard!) This fixes the bug that we weren't catching void foo() = delete; void foo() {} as being a redefinition. llvm-svn: 131013
* Implement support for C++0x alias templates.Richard Smith2011-05-051-0/+8
| | | | llvm-svn: 130953
* Revise the representation of parameter scope data so that theJohn McCall2011-05-021-3/+11
| | | | | | | scope depth overlaps with the ObjCDeclQualifier, dropping memory usage back to previous levels. llvm-svn: 130671
* Store a parameter index and function prototype depth in everyJohn McCall2011-05-011-0/+2
| | | | | | | | | | parameter node and use this to correctly mangle parameter references in function template signatures. A follow-up patch will improve the storage usage of these fields; here I've just done the lazy thing. llvm-svn: 130669
* Compress some bits. Only matters for MSVC, or if we everJohn McCall2011-05-011-10/+10
| | | | | | | devirtualize Decl (because bits can't get laid out in base classes if the base is POD). llvm-svn: 130632
* Re-applies the patch first applied way back in r106099, withChandler Carruth2011-05-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | accompanying fixes to make it work today. The core of this patch is to provide a link from a TemplateTypeParmType back to the TemplateTypeParmDecl node which declared it. This in turn provides much more precise information about the type, where it came from, and how it functions for AST consumers. To make the patch work almost a year after its first attempt, it needed serialization support, and it now retains the old getName() interface. Finally, it requires us to not attempt to instantiate the type in an unsupported friend decl -- specifically those coming from template friend decls but which refer to a specific type through a dependent name. A cleaner representation of the last item would be to build FriendTemplateDecl nodes for these, storing their template parameters etc, and to perform proper instantation of them like any other template declaration. They can still be flagged as unsupported for the purpose of access checking, etc. This passed an asserts-enabled bootstrap for me, and the reduced test case mentioned in the original review thread no longer causes issues, likely fixed at somewhere amidst the 24k revisions that have elapsed. llvm-svn: 130628
* Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout'Chandler Carruth2011-04-301-1/+1
| | | | | | | based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
* Completely re-implement the core logic behind the __is_standard_layoutChandler Carruth2011-04-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
* Serialize/deserialize the HasStandardLayout bit when writing/reading PCHs.Anders Carlsson2011-04-291-0/+1
| | | | llvm-svn: 130525
* Add a decl update when a static data member of a class template is ↵Sebastian Redl2011-04-291-3/+10
| | | | | | instantiated in a different PCH than its containing class. Otherwise we get double definition errors. Fixes a Boost.MPL problem that affects Boost.Accumulators and probably a lot more of Boost. llvm-svn: 130488
* Set the correct anonymous namespace (must be last reopening), and behave ↵Sebastian Redl2011-04-241-4/+9
| | | | | | correctly in the presence of the ever-annoying linkage specifications. llvm-svn: 130105
* Fix adding an anonymous namespace in a chained PCH to a namespace from a ↵Sebastian Redl2011-04-241-0/+10
| | | | | | | | previous PCH. Fix anonymous namespaces in PCH. llvm-svn: 130104
* On reading DeclContexts from PCH, check for visible updates even if the ↵Sebastian Redl2011-04-241-14/+18
| | | | | | context was empty in the original version. Also, if there are any, tell the context that it has external visible decls. This fixes the problem that a namespace that was empty in the initial PCH (could also happen if the initial PCH didn't include any std header but caused implicit creation of namespace std, e.g. due to implicit declaration of a virtual destructor) never found any declaration declared in *any* chained PCH. Very ugly when the chained PCH includes all that std stuff, as the errors were effectively the same as not including std headers. llvm-svn: 130102
* Implement most of the remaining logic in __is_literal type trait. ThisChandler Carruth2011-04-241-0/+2
| | | | | | | should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
* Begin tracking trivialness of move constructors and move assignmentChandler Carruth2011-04-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
* We regard a function as 'unused' from the codegen perspective, so our ↵Argyrios Kyrtzidis2011-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | warnings diverge from gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context (e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed is somewhat misleading. - Don't emit 'unused' warnings for functions that are referenced in any part of the user's code. - A warning that an internal function/variable won't get emitted is useful though, so introduce -Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not "needed" ('used' from the codegen perspective), e.g: static void foo() { } template <int> void bar() { foo(); } test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted static void foo() { } ^ Addresses rdar://8733476. llvm-svn: 129794
* Support for C++11 (non-template) alias declarations.Richard Smith2011-04-151-3/+13
| | | | llvm-svn: 129567
* Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith2011-04-141-0/+1
| | | | | | draft standard (N3291). llvm-svn: 129541
* Add a bit to ParmVarDecl indicating whether the parameter undergoes John McCall2011-03-091-0/+1
| | | | | | K&R-style default argument promotion. llvm-svn: 127313
* Teach libclang's token-annotation logic about context-sensitiveDouglas Gregor2011-03-081-1/+2
| | | | | | keywords for Objective-C+ and C++0x. llvm-svn: 127253
* Fixed source range for StaticAssertDecl and LinkageSpecDecl. Fixed source ↵Abramo Bagnara2011-03-081-2/+5
| | | | | | range for declarations using postfix types. llvm-svn: 127251
* Fixed NamespaceDecl source range.Abramo Bagnara2011-03-081-3/+4
| | | | llvm-svn: 127242
* Fixed source range for all DeclaratorDecl's.Abramo Bagnara2011-03-081-19/+21
| | | | llvm-svn: 127225
* Completed source ranges fixes for all classes inheriting from TypeDecl.Abramo Bagnara2011-03-061-2/+0
| | | | llvm-svn: 127120
* Fixed TypedefDecl and TemplateTypeParameter source range.Abramo Bagnara2011-03-061-1/+3
| | | | llvm-svn: 127119
* Fixed LabelDecl source range and cleaned creation code.Abramo Bagnara2011-03-051-2/+1
| | | | llvm-svn: 127094
* When we're deserializing a template parameter declaration, temporarilyDouglas Gregor2011-03-051-2/+24
| | | | | | | | | | use the translation unit as its declaration context, then deserialize the actual lexical and semantic DeclContexts after the template parameter is complete. This avoids problems when the DeclContext itself (e.g., a class template) is dependent on the template parameter (e.g., for the injected-class-name). llvm-svn: 127056
* Make sure to put template parameters into their owning template'sDouglas Gregor2011-03-041-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
* Fixed source range for LabelDecl.Abramo Bagnara2011-03-031-0/+2
| | | | llvm-svn: 126952
* Removed left brace location from LinkageSpecDecl.Abramo Bagnara2011-03-031-2/+1
| | | | llvm-svn: 126945
* Fixed end source location for LinkageSpecDecl.Abramo Bagnara2011-03-031-2/+3
| | | | llvm-svn: 126943
* Fixed source range for FileScopeAsmDecl. Others source range fixes will follow.Abramo Bagnara2011-03-031-1/+3
| | | | llvm-svn: 126939
* Push nested-name-specifier source location information into namespaceDouglas Gregor2011-02-251-3/+3
| | | | | | aliases. llvm-svn: 126496
* Push nested-name-specifier source location information into using directives.Douglas Gregor2011-02-251-3/+2
| | | | llvm-svn: 126489
* Update UsingDecl, UnresolvedUsingTypenameDecl, andDouglas Gregor2011-02-251-11/+10
| | | | | | | | | | | | | | UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
* Step #2/N of __label__ support: keep pushing LabelDecl forward,Chris Lattner2011-02-171-1/+0
| | | | | | | | | | making them be template instantiated in a more normal way and make them handle attributes like other decls. This fixes the used/unused label handling stuff, making it use the same infrastructure as other decls. llvm-svn: 125771
* Step #1/N of implementing support for __label__: split labels intoChris Lattner2011-02-171-0/+10
| | | | | | | | | | | | | | | | | | | LabelDecl and LabelStmt. There is a 1-1 correspondence between the two, but this simplifies a bunch of code by itself. This is because labels are the only place where we previously had references to random other statements, causing grief for AST serialization and other stuff. This does cause one regression (attr(unused) doesn't silence unused label warnings) which I'll address next. This does fix some minor bugs: 1. "The only valid attribute " diagnostic was capitalized. 2. Various diagnostics printed as ''labelname'' instead of 'labelname' 3. This reduces duplication of label checking between functions and blocks. Review appreciated, particularly for the cindex and template bits. llvm-svn: 125733
* When reading the AST, delay loading of the redeclaration chain to avoid ↵Argyrios Kyrtzidis2011-02-121-9/+49
| | | | | | | | | | | deeply nested calls. Temporarily set the first (canonical) declaration as the previous one, which is the one that matters, and mark the real previous DeclID to be loaded & attached later on. Fixes rdar://8956193. llvm-svn: 125434
* NonTypeTemplateParmDecl is just a DeclaratorDecl, not a VarDecl.John McCall2011-02-091-1/+1
| | | | | | | Also, reorganize and make very explicit the logic for determining the value kind and type of a referenced declaration. llvm-svn: 125150
* A few more tweaks to the blocks AST representation: John McCall2011-02-071-7/+14
| | | | | | | | | | | | | | | | | - BlockDeclRefExprs always store VarDecls - BDREs no longer store copy expressions - BlockDecls now store a list of captured variables, information about how they're captured, and a copy expression if necessary With that in hand, change IR generation to use the captures data in blocks instead of walking the block independently. Additionally, optimize block layout by emitting fields in descending alignment order, with a heuristic for filling in words when alignment of the end of the block header is insufficient for the most aligned field. llvm-svn: 125005
* An insomniac stab at making block declarations list the variables they closeJohn McCall2011-02-021-0/+9
| | | | | | | on, as well as more reliably limiting invalid references to locals from nested scopes. llvm-svn: 124721
* Use attributes for all the override control specifiers.Anders Carlsson2011-01-241-5/+0
| | | | llvm-svn: 124122
* Serialize and deserialize IsMarkedFinal/IsMarkedExplicit.Anders Carlsson2011-01-221-0/+3
| | | | llvm-svn: 124041
* Generalise support for non-inheritable attributesPeter Collingbourne2011-01-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Inheritable attributes on declarations may be inherited by any later redeclaration at merge time. By contrast, a non-inheritable attribute will not be inherited by later redeclarations. Non-inheritable attributes may be semantically analysed early, allowing them to influence the redeclaration/overloading process. Before this change, the "overloadable" attribute received special handling to be treated as non-inheritable, while all other attributes were treated as inheritable. This patch generalises the concept, while removing a FIXME. Some CUDA location attributes are also marked as non-inheritable in order to support special overloading semantics (to be introduced in a later patch). The patch introduces a new Attr subclass, InheritableAttr, from which all inheritable attributes derive. Non-inheritable attributes simply derive from Attr. N.B. I did not review every attribute to determine whether it should be marked non-inheritable. This can be done later on an incremental basis, as this change does not affect default functionality. llvm-svn: 123959
* Add IsMarkedOverride and IsMarkedFinal flags to FunctionDecl (to be used by ↵Anders Carlsson2011-01-201-0/+3
| | | | | | CXXRecordDecl). llvm-svn: 123885
OpenPOWER on IntegriCloud