summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTReaderDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Implement support for non-type template parameter packs whose type isDouglas Gregor2011-01-191-7/+20
| | | | | | | | | | | | | | | | | | | | | a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
* Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter,Alexis Hunt2011-01-081-3/+3
| | | | | | | more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
* Implement support for template template parameter packs, e.g.,Douglas Gregor2011-01-051-1/+3
| | | | | | | template<template<class> class ...Metafunctions> struct apply_to_each; llvm-svn: 122874
* In the latest episode of "Deserializing bugs caused by accessors" the series ↵Argyrios Kyrtzidis2011-01-031-9/+9
| | | | | | | | | | reached a thrilling climax when FunctionDecl::setPure crashed a poor user's code. Remove the use of this accessor when deserializing, along with several other in the neighborhood. Fixes rdar://8759653. llvm-svn: 122756
* Add an AST representation for non-type template parameterDouglas Gregor2010-12-231-1/+2
| | | | | | | | | | | | | | packs, e.g., template<typename T, unsigned ...Dims> struct multi_array; along with semantic analysis support for finding unexpanded non-type template parameter packs in types, expressions, and so on. Template instantiation involving non-type template parameter packs probably doesn't work yet. That'll come soon. llvm-svn: 122527
* Eliminate the branching in QualType::getTypePtr() by providing aDouglas Gregor2010-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | common base for ExtQuals and Type that stores the underlying type pointer. This results in a 2% performance win for -emit-llvm on a typical C file, with 1% memory growth in the AST. Note that there is an API change in this optimization: QualType::getTypePtr() can no longer be invoked on a NULL QualType. If the QualType might be NULL, use QualType::getTypePtrOrNull(). I've audited all uses of getTypePtr() in the code base and changed the appropriate uses over to getTypePtrOrNull(). A future optimization opportunity would be to distinguish between cast/dyn_cast and cast_or_null/dyn_cast_or_null; for the former, we could use getTypePtr() rather than getTypePtrOrNull(), to take another branch out of the cast/dyn_cast implementation. llvm-svn: 121489
* When an "inline" declaration was followed by a definition not markedDouglas Gregor2010-12-091-1/+2
| | | | | | | | | | | | | "inline", we weren't giving the definition weak linkage because the "inline" bit wasn't propagated. This was a longstanding FIXME that, somehow, hadn't triggered a bug in the wild. Fix this problem by tracking whether any declaration was marked "inline", and clean up the semantics of GNU's "extern inline" semantics calculation based on this change. Fixes <rdar://problem/8740363>. llvm-svn: 121373
* Re-implement caching for the linkage calculation of declarations.Douglas Gregor2010-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | My previous attempt at solving the compile-time problem with many redeclarations of the same entity cached both linkage and visibility, while this patch only tackles linkage. There are several reasons for this difference: - Linkage is a language concept, and is evaluated many times during semantic analysis and codegen, while visibility is only a code-generation concept that is evaluated only once per (unique) declaration. Hence, we *must* optimize linkage calculations but don't need to optimize visibility computation. - Once we know the linkage of a declaration, subsequent redeclarations can't change that linkage. Hence, cache invalidation is far simpler than for visibility, where a later redeclaration can completely change the visibility. - We have 3 spare bits in Decl to store the linkage cache, so the cache doesn't increase the size of declarations. With the visibility+linkage cache, NamedDecl got larger. llvm-svn: 121023
* Revert r120808, my previous implementation of caching for the linkageDouglas Gregor2010-12-061-2/+2
| | | | | | | | | and visibility of declarations, because it was extremely messy and it increased the size of NamedDecl. An improved implementation is forthcoming. llvm-svn: 121012
* Added struct/class syntactic info for c++0x scoped enum.Abramo Bagnara2010-12-031-0/+1
| | | | llvm-svn: 120828
* Implement caching for the linkage and visibility calculations ofDouglas Gregor2010-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | declarations. The motivation for this patch is that linkage/visibility computations are linear in the number of redeclarations of an entity, and we've run into a case where a single translation unit has > 6500 redeclarations of the same (unused!) external variable. Since each redeclaration involves a linkage check, the resulting quadratic behavior makes Clang slow to a crawl. With this change, a simple test with 512 redeclarations of a variable syntax-checks ~20x faster than before. That said, I hate this change, and will probably end up reverting it in a few hours. Reasons to hate it: - It makes NamedDecl larger, since we don't have enough free bits in Decl to squeeze in the extra information about caching. - There are way too many places where we need to invalidate this cache, because the visibility of a declaration can change due to redeclarations (!). Despite self-hosting and passing the testsuite, I have no confidence that I've found all of places where this cache needs to be invalidated. llvm-svn: 120808
OpenPOWER on IntegriCloud