summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/PreprocessingRecord.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [preprocessor] Use MacroDirective in the preprocessor callbacks to make ↵Argyrios Kyrtzidis2013-02-241-15/+16
| | | | | | | | available the full information about the macro (e.g if it was imported and where). llvm-svn: 175978
* [preprocessing record] Have the MacroDefinitions map point to the ↵Argyrios Kyrtzidis2013-02-221-9/+7
| | | | | | | | | | MacroDefinition object instead its index in the preprocessed entities vector. This is because the order of the entities in the vector can change in some (uncommon) cases. llvm-svn: 175907
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-2/+2
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* [preprocessing record] Add some sanity checks for the preprocessed entity indexArgyrios Kyrtzidis2013-02-121-4/+8
| | | | | | | | to make sure we don't crash on release if the index is not valid. rdar://13089714 llvm-svn: 175010
* [preprocessor] Call the MacroUndefined callback even when the macro was not ↵Argyrios Kyrtzidis2013-01-161-1/+3
| | | | | | | | defined. Patch by Enea Zaffanella! llvm-svn: 172623
* [PreprocessingRecord] A macro expansion can be reported out-of-order in ↵Argyrios Kyrtzidis2013-01-091-3/+11
| | | | | | | | | | | | cases when there are macro expansions inside macro arguments where the arguments are not expanded in the same order as listed; don't assert that all macro expansions are in source order. rdar://12397063 llvm-svn: 172018
* [libclang] Resolve a cursor that points to a macro name inside a #ifdef/#ifndefArgyrios Kyrtzidis2012-12-081-2/+29
| | | | | | | | | | directive as a macro expansion. This is more of a "macro reference" than a macro expansion but it's close enough for libclang's purposes. If it causes issues we can revisit and introduce a new kind of cursor. llvm-svn: 169666
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-1/+1
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Refactor recording the preprocessor conditional directive regions out ofArgyrios Kyrtzidis2012-12-041-99/+2
| | | | | | | | | PreprocessingRecord and into its own class, PPConditionalDirectiveRecord. Decoupling allows a client to use the functionality of PPConditionalDirectiveRecord without needing a PreprocessingRecord. llvm-svn: 169229
* In the PreprocessingRecord, to identify the different conditional directive ↵Argyrios Kyrtzidis2012-12-041-16/+19
| | | | | | | | regions use the SourceLocation at the start of the respective region, instead of a unique integer. llvm-svn: 169228
* [preprocessing record] Have PPEntityID be independent of the size of theArgyrios Kyrtzidis2012-10-051-14/+18
| | | | | | | loaded entities vector, otherwise its meaning will change when a module is imported and the vector size changes. llvm-svn: 165278
* Add info in the preprocessing record whether an inclusion directiveArgyrios Kyrtzidis2012-10-021-3/+5
| | | | | | resulted in an automatic module import. llvm-svn: 165022
* For PPCallbacks::InclusionDirective() add a parameter for the module, wheneverArgyrios Kyrtzidis2012-09-291-1/+2
| | | | | | | an inclusion directive was automatically turned into a module import, and PPCallbacks::moduleImport() for an explicit module import. llvm-svn: 164874
* Per discussion in ↵Argyrios Kyrtzidis2012-09-271-2/+11
| | | | | | | | | | http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120917/064551.html have PPCallbacks::InclusionDirective pass the character range for the filename quotes or brackets. rdar://11113134 & http://llvm.org/PR13880 llvm-svn: 164743
* Documentation cleanup:James Dennett2012-06-221-2/+2
| | | | | | | * Use \p param for a parameter reference, not the (erroneous) form \arg param; * Escape # characters in Doxygen comments as needed. llvm-svn: 158971
* [preprocessor] Handle correctly inclusion directives that have macro ↵Argyrios Kyrtzidis2012-03-271-16/+39
| | | | | | | | | | | | | | | | | | expansions, e.g "#include MACRO(STUFF)". -As an inclusion position for the included file, use the file location of the file where it was included but *after* the macro expansions. We want the macro expansions to be considered as before-in-translation-unit for everything in the included file. -In the preprocessing record take into account that only inclusion directives can be encountered as "out-of-order" (by comparing the start of the range which for inclusions is the hash location) and use binary search if there is an extreme number of macro expansions in the include directive. Fixes rdar://11111779 llvm-svn: 153527
* Simplify some users of DenseMap::erase.Benjamin Kramer2012-03-241-4/+1
| | | | llvm-svn: 153389
* [preprocessor] Enhance PreprocessingRecord to keep track of locations of ↵Argyrios Kyrtzidis2012-03-051-2/+96
| | | | | | | | | conditional directives. Introduce PreprocessingRecord::rangeIntersectsConditionalDirective() which returns true if a given range intersects with a conditional directive block. llvm-svn: 152018
* Don't record nested macro expansions in the preprocessing record,Argyrios Kyrtzidis2012-02-251-5/+4
| | | | | | | | it can only bring pain when dealing with preprocessor abuse (see: boost). rdar://10898986 llvm-svn: 151427
* Remove unreachable code in Clang. (replace with llvm_unreachable where ↵David Blaikie2012-01-171-1/+0
| | | | | | appropriate or when GCC requires it) llvm-svn: 148292
* [PCH] When visiting preprocessed entities, make it possible to avoid ↵Argyrios Kyrtzidis2011-10-251-16/+89
| | | | | | | | | | | | | | | deserializing preprocessed entities that are #included in the range that we are interested. This is useful when we are interested in preprocessed entities of a specific file, e.g when we are annotating tokens. There is also an optimization where we cache the last result of PreprocessingRecord::getPreprocessedEntitiesInRange and we re-use it if there is a call with the same range as before. rdar://10313365 llvm-svn: 142887
* Handle the case where preprocessor entities are not received in order,Argyrios Kyrtzidis2011-10-121-5/+25
| | | | | | fixes http://llvm.org/PR11120 llvm-svn: 141788
* Do manual binary search for preprocessing entities because their end locationsArgyrios Kyrtzidis2011-09-221-5/+23
| | | | | | may be unordered and MSVC's debug-mode doesn't like it. llvm-svn: 140337
* More MSVC9 unbreaking.Benjamin Kramer2011-09-211-2/+8
| | | | llvm-svn: 140256
* [libclang] When pointing at a macro expansion inside a macro argument,Argyrios Kyrtzidis2011-09-201-3/+3
| | | | | | return a cursor for the inner macro. llvm-svn: 140207
* The location of the name in MacroDefinition is the beginning of its range,Argyrios Kyrtzidis2011-09-201-3/+1
| | | | | | don't store an extra location for it. llvm-svn: 140190
* Fix gcc build.Argyrios Kyrtzidis2011-09-191-1/+2
| | | | llvm-svn: 140073
* Introduce local_begin()/local_end() methods in PreprocessingRecord whichArgyrios Kyrtzidis2011-09-191-12/+0
| | | | | | return iterators for local, non-loaded, preprocessed entities. llvm-svn: 140062
* Introduce PreprocessingRecord::getPreprocessedEntitiesInRange()Argyrios Kyrtzidis2011-09-191-6/+111
| | | | | | | | | | which will do a binary search and return a pair of iterators for preprocessed entities in the given source range. Source ranges of preprocessed entities are stored twice currently in the PCH/Module file but this will be fixed in a subsequent commit. llvm-svn: 140058
* [PCH] Overhaul how preprocessed entities are [de]serialized.Argyrios Kyrtzidis2011-09-151-26/+38
| | | | | | | | | | | | | -Use an array of offsets for all preprocessed entities -Get rid of the separate array of offsets for just macro definitions; for references to macro definitions use an index inside the preprocessed entities array. -Deserialize each preprocessed entity lazily, at first request; not in bulk. Paves the way for binary searching of preprocessed entities that will offer efficiency and will simplify things on the libclang side a lot. llvm-svn: 139809
* [libclang] Fix annotation and getting a "macro expansion" cursorArgyrios Kyrtzidis2011-09-081-4/+5
| | | | | | for a builtin macro expansion. llvm-svn: 139298
* For the MacroExpands preprocessor callback, also pass the SourceRangeArgyrios Kyrtzidis2011-08-181-2/+3
| | | | | | of expansion (for function macros it includes the right paren). llvm-svn: 137909
* Change PreprocessingRecord::getTotalMemory() to use llvm::capacity_in_bytes().Ted Kremenek2011-07-271-3/+4
| | | | llvm-svn: 136238
* Report more memory using in Preprocessor::getTotalMemory() and ↵Ted Kremenek2011-07-261-0/+7
| | | | | | | | | | PreprocessingRecord::getTotalMemory(). Most of the memory was already reported; but now we report more memory from side data structures. Fixes <rdar://problem/9379717>. llvm-svn: 136150
* remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner2011-07-231-5/+5
| | | | | | | | LLVM.h imports them into the clang namespace. llvm-svn: 135852
* Rework the detailed preprocessing record to separate preprocessingDouglas Gregor2011-07-211-31/+18
| | | | | | | | | | | | | | | entities generated directly by the preprocessor from those loaded from the external source (e.g., the ASTReader). By separating these two sets of entities into different vectors, we allow both to grow independently, and eliminate the need for preallocating all of the loaded preprocessing entities. This is similar to the way the recent SourceManager refactoring treats FileIDs and the source location address space. As part of this, switch over to building a continuous range map to track preprocessing entities. llvm-svn: 135646
* Move the rest of the preprocessor terminology from 'instantiate' andChandler Carruth2011-07-141-6/+5
| | | | | | | | | | | | | variants to 'expand'. This changed a couple of public APIs, including one public type "MacroInstantiation" which is now "MacroExpansion". The rest of the codebase was updated to reflect this, especially the libclang code. Two of the C++ (and thus easily changed) libclang APIs were updated as well because they pertained directly to the old MacroInstantiation class. No functionality changed. llvm-svn: 135139
* Introduce a new libclang parsing flag,Douglas Gregor2011-05-061-2/+6
| | | | | | | | | | | | | CXTranslationUnit_NestedMacroInstantiations, which indicates whether we want to see "nested" macro instantiations (e.g., those that occur inside other macro instantiations) within the detailed preprocessing record. Many clients (e.g., those that only care about visible tokens) don't care about this information, and in code that uses preprocessor metaprogramming, this information can have a very high cost. Addresses <rdar://problem/9389320>. llvm-svn: 130990
* To be able to replay compilations we need to accurately remodel howManuel Klimek2011-04-261-1/+2
| | | | | | | | | includes get resolved, especially when they are found relatively to another include file. We also try to get it working for framework includes, but that part of the code is untested, as I don't have a code base that uses it. llvm-svn: 130246
* Add a 'RawPath' parameter to the PPCallbacks interface. This allowsChandler Carruth2011-03-161-6/+8
| | | | | | | | | | | | | | | clients to observe the exact path through which an #included file was located. This is very useful when trying to record and replay inclusion operations without it beind influenced by the aggressive caching done inside the FileManager to avoid redundant system calls and filesystem operations. The work to compute and return this is only done in the presence of callbacks, so it should have no effect on normal compilation. Patch by Manuel Klimek. llvm-svn: 127742
* Several PPCallbacks take an SourceLocation + IdentifierInfo, ratherCraig Silverstein2010-11-191-4/+5
| | | | | | | | | | | than a Token that holds the same information all in one easy-to-use package. There's no technical reason to prefer the former -- the information comes from a Token originally -- and it's clumsier to use, so I've changed the code to use tokens everywhere. Approved by clattner llvm-svn: 119845
* Plug a leak in the preprocessing record's handling of inclusionDouglas Gregor2010-11-011-2/+18
| | | | | | | directives. We had a std::string in an object that was allocated via a BumpPtrAllocator. llvm-svn: 117912
* Extend the preprocessing record and libclang with support forDouglas Gregor2010-10-201-0/+37
| | | | | | | | | inclusion directives, keeping track of every #include, #import, etc. in the translation unit. We keep track of the source location and kind of the inclusion, how the file name was spelled, and the underlying file to which the inclusion resolved. llvm-svn: 116952
* Push location through the MacroUndefined PPCallback and use it to print ↵Benjamin Kramer2010-08-071-1/+2
| | | | | | #undefs in -dD mode. (PR7818) llvm-svn: 110523
* Robustify PreprocessingRecord slightly, by only creating macroDouglas Gregor2010-03-191-3/+12
| | | | | | | | instantiations when we have the corresponding macro definition and by removing macro definition information from our table when the macro is undefined. llvm-svn: 99004
* Implement serialization and lazy deserialization of the preprocessingDouglas Gregor2010-03-191-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | record (which includes all macro instantiations and definitions). As with all lay deserialization, this introduces a new external source (here, an external preprocessing record source) that loads all of the preprocessed entities prior to iterating over the entities. The preprocessing record is an optional part of the precompiled header that is disabled by default (enabled with -detailed-preprocessing-record). When the preprocessor given to the PCH writer has a preprocessing record, that record is written into the PCH file. When the PCH reader is given a PCH file that contains a preprocessing record, it will be lazily loaded (which, effectively, implicitly adds -detailed-preprocessing-record). This is the first case where we have sections of the precompiled header that are added/removed based on a compilation flag, which is unfortunate. However, this data consumes ~550k in the PCH file for Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering this detailed preprocessing information, so it's too expensive to turn on by default. In the future, we should investigate a better encoding of this information. llvm-svn: 99002
* Make the preprocessing record a PPCallbacks subclass itself,Douglas Gregor2010-03-191-0/+24
| | | | | | | | eliminating the extra PopulatePreprocessingRecord object. This will become useful once we start writing the preprocessing record to precompiled headers. llvm-svn: 98966
* Optionally store a PreprocessingRecord in the preprocessor itself, andDouglas Gregor2010-03-191-16/+0
| | | | | | tie its creation to a CC1 flag -detailed-preprocessing-record. llvm-svn: 98963
* Explicitly link macro instantiations to macro definitions in theDouglas Gregor2010-03-181-3/+5
| | | | | | | | preprocessing record. Use that link with clang_getCursorReferenced() and clang_getCursorDefinition() to match instantiations of a macro to the definition of the macro. llvm-svn: 98842
* Introduce the notion of a "preprocessing record", which keeps track ofDouglas Gregor2010-03-181-0/+37
the macro definitions and macro instantiations that are found during preprocessing. Preprocessing records are *not* generated by default; rather, we provide a PPCallbacks subclass that hooks into the existing callback mechanism to record this activity. The only client of preprocessing records is CIndex, which keeps track of macro definitions and instantations so that they can be exposed via cursors. At present, only token annotation uses these facilities, and only for macro instantiations; both will change in the near future. However, with this change, token annotation properly annotates macro instantiations that do not produce any tokens and instantiations of macros that are later undef'd, improving our consistency. Preprocessing directives that are not macro definitions are still handled by clang_annotateTokens() via re-lexing, so that we don't have to track every preprocessing directive in the preprocessing record. Performance impact of preprocessing records is still TBD, although it is limited to CIndex and therefore out of the path of the main compiler. llvm-svn: 98836
OpenPOWER on IntegriCloud