summaryrefslogtreecommitdiffstats
path: root/clang/lib/Lex/PreprocessingRecord.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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