summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Keep track of the file ID corresponding to the original file used toDouglas Gregor2011-05-061-1/+6
| | | | | | | | | | | build a precompiled header. Use this information to eliminate the call to SourceManager::getLocation() while loading a precompiled preamble, since SourceManager::getLocation() itself causes unwanted deserialization. Fixed <rdar://problem/9399352>. llvm-svn: 131021
* Implement support for C++0x alias templates.Richard Smith2011-05-051-1/+2
| | | | llvm-svn: 130953
* there i fixed itAlexis Hunt2011-05-041-0/+21
| | | | | | | | | Increase robustness of the delegating constructor cycle detection mechanism. No more infinite loops on invalid or logic errors leading to false results. Ensure that this is maintained correctly accross serialization. llvm-svn: 130887
* Implement serialization of delegating constructors.Alexis Hunt2011-05-041-6/+9
| | | | llvm-svn: 130822
* Introduce a new libclang API, clang_isFileMultipleIncludeGuarded(),Douglas Gregor2011-05-041-1/+2
| | | | | | | | which determines whether a particular file is actually a header that is intended to be guarded from multiple inclusions within the same translation unit. llvm-svn: 130808
* Re-applies the patch first applied way back in r106099, withChandler Carruth2011-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+12
| | | | | | 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
* Use template magic to make dumping of vectors slightly less fragile.Benjamin Kramer2011-04-241-27/+18
| | | | | | No intended functionality change. llvm-svn: 130114
* Synthesizing the definition of an implicit member is an AST modification, so ↵Sebastian Redl2011-04-241-0/+9
| | | | | | notify any mutation listeners of it. This fixes a crasher in chained PCH, where an implicit destructor in a PCH gets a definition in a chained PCH, which is then lost. However, any further use of the destructor would cause its definition to be regenerated in the final file, hiding the bug. llvm-svn: 130103
* Store the full list of pending instantiations in a chained PCH. Previously ↵Sebastian Redl2011-04-241-4/+2
| | | | | | we attempted to store only new pending instantiations, but our filter was incorrect, dropping implicit instantiations of class template members. It's just not worth coming up with a complex filter that is correct, when the only cost is PCH files that are a few hundred bytes (at most) larger. llvm-svn: 130098
* 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
* Teach the AST reader and writer to preserve the __DEPRECATED bit inChandler Carruth2011-04-231-0/+1
| | | | | | | | | | | language options, and warn when reading an AST with a different value for the bit. There doesn't appear to be a good way to test this (commenting out similar other language options doesn't break anything) but if folks have suggestions on tests I'm happy to add them. llvm-svn: 130071
* fix a bunch of comment typos found by codespell. Patch byChris Lattner2011-04-151-2/+2
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129559
* C1X: implement generic selectionsPeter Collingbourne2011-04-151-0/+1
| | | | | | | As an extension, generic selection support has been added for all supported languages. The syntax is the same as for C1X. llvm-svn: 129554
* C1X: add a language standardPeter Collingbourne2011-04-151-0/+1
| | | | llvm-svn: 129553
* Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith2011-04-141-0/+2
| | | | | | draft standard (N3291). llvm-svn: 129541
* Chained PCH: Remember when additional specializations are added to a ↵Sebastian Redl2011-04-141-0/+12
| | | | | | function template from a previous PCH. Fixes the only crasher when using massive chains on Clang's Sema component. We still have some incomplete codegen there. llvm-svn: 129516
* Fix AST serialization of reference-to-reference types. This previously causedRichard Smith2011-04-121-2/+3
| | | | | | | | | a crash when deserializing the AST for this: typedef char (&R); extern R &r; llvm-svn: 129358
* PR8369: make __attribute((regparm(0))) work correctly. Original patch byEli Friedman2011-04-091-0/+1
| | | | | | pageexec@freemail.hu, tweaks by me. llvm-svn: 129206
* Implement a new 'availability' attribute, that allows one to specifyDouglas Gregor2011-03-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. llvm-svn: 128127
* Propagate the new exception information to FunctionProtoType.Sebastian Redl2011-03-121-5/+8
| | | | | | | | Change the interface to expose the new information and deal with the enormous fallout. Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications. Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support. llvm-svn: 127537
* Forgotten part of previous commit.Abramo Bagnara2011-03-121-2/+2
| | | | llvm-svn: 127536
* When writing file references in a pch, make sure to ask the file manager for ↵Anders Carlsson2011-03-081-0/+7
| | | | | | the absolute path. llvm-svn: 127248
* Write CXX base specifier offsets for chained ASTs.Anders Carlsson2011-03-061-19/+27
| | | | llvm-svn: 127126
* Improved MemberPointerType source locations.Abramo Bagnara2011-03-051-0/+1
| | | | llvm-svn: 127085
* Currently we can only remap a file by creating a MemoryBuffer and replacing ↵Argyrios Kyrtzidis2011-03-051-5/+8
| | | | | | | | | the file contents with it. Allow remapping a file by specifying another filename whose contents should be loaded if the original file gets loaded. This allows to override files without having to create & load buffers in advance. llvm-svn: 127052
* Push nested-name-specifier source location information into templateDouglas Gregor2011-03-021-2/+2
| | | | | | | | | | | | template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. llvm-svn: 126844
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-011-1/+1
| | | | | | | | template specialization types. There are still a few rough edges to clean up with some of the parser actions dropping nested-name-specifiers too early. llvm-svn: 126776
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
* Implement -mrtd which sets the StdCall calling convention to be the defaultRoman Divacky2011-03-011-0/+1
| | | | | | one. llvm-svn: 126756
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-011-1/+1
| | | | | | location information for elaborated types. *sigh* llvm-svn: 126753
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | information for qualifier type names throughout the parser to address several problems. The commit message from r126737: Push nested-name-specifier source location information into elaborated name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. llvm-svn: 126748
* Revert r126737, the most recent nested-name-specifier location change, for ↵Douglas Gregor2011-03-011-1/+1
| | | | | | buildbot breakage. llvm-svn: 126746
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-011-1/+1
| | | | | | | | | | | | | | | | | | | name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. llvm-svn: 126737
* Push nested-name-specifier source location information intoDouglas Gregor2011-03-011-1/+1
| | | | | | | | | | | | DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to walk DependentNameTypeLoc nodes. Also, teach libclang about TypedefDecl source ranges, so that we get those. The massive churn in test/Index/recursive-cxx-member-calls.cpp is a good thing: we're annotating a lot more of this test correctly now. llvm-svn: 126729
* Use NestedNameSpecifierLoc within out-of-line variables, function, andDouglas Gregor2011-02-251-2/+1
| | | | | | | tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
* Update UsingDecl, UnresolvedUsingTypenameDecl, andDouglas Gregor2011-02-251-3/+58
| | | | | | | | | | | | | | 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
* Teach NestedNameSpecifier to keep track of namespace aliases the sameDouglas Gregor2011-02-241-0/+4
| | | | | | | | way it keeps track of namespaces. Previously, we would map from the namespace alias to its underlying namespace when building a nested-name-specifier, losing source information in the process. llvm-svn: 126358
* Add a CXXExceptions flag to LangOptions.Anders Carlsson2011-02-231-1/+2
| | | | llvm-svn: 126299
* Implement the C++0x deduced 'auto' feature.Richard Smith2011-02-201-0/+8
| | | | | | This fixes PR 8738, 9060 and 9132. llvm-svn: 126069
* Add a new ObjCExceptions member variable to LangOptions. This controls ↵Anders Carlsson2011-02-191-0/+1
| | | | | | whether Objective-C exceptions are enabled or not (they are by default). llvm-svn: 126061
* Serialization/deserialization support for floating point #pragmaPeter Collingbourne2011-02-151-0/+28
| | | | | | options, enabled OpenCL extensions and default FP_CONTRACT setting. llvm-svn: 125589
* Allow resolving headers from a PCH even after headers+PCH were moved to ↵Argyrios Kyrtzidis2011-02-151-5/+25
| | | | | | | | | | | another path. Store in PCH the directory that the PCH was originally created in. If a header file is not found at the path that we expect it to be and the PCH file was moved from its original location, try to resolve the file by assuming that header+PCH were moved together and the header is in the same place relative to the PCH. llvm-svn: 125576
* Eliminate a major performance problem with chained PCH, where we wereDouglas Gregor2011-02-111-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | causing the deserialization of a large number of declarations when writing the visible-updates record for the translation unit in C. This takes us from: *** AST File Statistics: 2 stat cache hits 6 stat cache misses 1/64463 source location entries read (0.001551%) 15606/16956 types read (92.038216%) 59266/89334 declarations read (66.342041%) 38952/61393 identifiers read (63.446976%) 0/7778 selectors read (0.000000%) 24192/34644 statements read (69.830276%) 388/8809 macros read (4.404586%) 2095/5189 lexical declcontexts read (40.373867%) 0/4587 visible declcontexts read (0.000000%) 0/7716 method pool entries read (0.000000%) 0 method pool misses to *** AST File Statistics: 2 stat cache hits 6 stat cache misses 1/64463 source location entries read (0.001551%) 26/16956 types read (0.153338%) 18/89334 declarations read (0.020149%) 145/61393 identifiers read (0.236183%) 0/7778 selectors read (0.000000%) 21/34644 statements read (0.060617%) 0/8809 macros read (0.000000%) 0/5189 lexical declcontexts read (0.000000%) 0/4587 visible declcontexts read (0.000000%) 0/7716 method pool entries read (0.000000%) 0 method pool misses when generating a chained PCH for a header that #includes Cocoa.h (from a PCH file) and adds one simple function declaration. The generated PCH file is now only 9580 bytes (down from > 2MB). llvm-svn: 125326
* Implement AST/PCH chaining support for macro definitions. Previously,Douglas Gregor2011-02-111-3/+16
| | | | | | | | | | | | | | we would deserialize all of the macro definitions we knew about while serializing the macro definitions at the end of the AST/PCH file. Even though we skipped most of them (since they were unchanged), it's still a performance problem. Now, we do the standard AST/PCH chaining trick: watch what identifiers are deserialized as macro names, and consider only those identifiers (along with macro definitions that have been deserialized/written in the source) when serializing the preprocessor state. llvm-svn: 125324
* When we're writing macro definitions to an AST/PCH File, sort theDouglas Gregor2011-02-101-7/+27
| | | | | | | macro definitions by macro name first. That way, we'll get a stable ordering in the AST/PCH file. llvm-svn: 125297
OpenPOWER on IntegriCloud