Commit Graph

28 Commits

Author SHA1 Message Date
Argyrios Kyrtzidis e523e389b2 Do manual binary search for preprocessing entities because their end locations
may be unordered and MSVC's debug-mode doesn't like it.

llvm-svn: 140337
2011-09-22 21:17:02 +00:00
Benjamin Kramer 2e9d9cfc39 More MSVC9 unbreaking.
llvm-svn: 140256
2011-09-21 16:58:20 +00:00
Argyrios Kyrtzidis 45e8cf5732 [libclang] When pointing at a macro expansion inside a macro argument,
return a cursor for the inner macro.

llvm-svn: 140207
2011-09-20 23:27:33 +00:00
Argyrios Kyrtzidis 0d48fb89c0 The location of the name in MacroDefinition is the beginning of its range,
don't store an extra location for it.

llvm-svn: 140190
2011-09-20 22:14:48 +00:00
Argyrios Kyrtzidis a35c4441b3 Fix gcc build.
llvm-svn: 140073
2011-09-19 22:02:08 +00:00
Argyrios Kyrtzidis 7f44836998 Introduce local_begin()/local_end() methods in PreprocessingRecord which
return iterators for local, non-loaded, preprocessed entities.

llvm-svn: 140062
2011-09-19 20:40:42 +00:00
Argyrios Kyrtzidis 64f6381097 Introduce PreprocessingRecord::getPreprocessedEntitiesInRange()
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
2011-09-19 20:40:25 +00:00
Argyrios Kyrtzidis 03c40c5182 [PCH] Overhaul how preprocessed entities are [de]serialized.
-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
2011-09-15 18:02:56 +00:00
Argyrios Kyrtzidis 80f78b961a [libclang] Fix annotation and getting a "macro expansion" cursor
for a builtin macro expansion.

llvm-svn: 139298
2011-09-08 17:18:41 +00:00
Argyrios Kyrtzidis 85a14bbd31 For the MacroExpands preprocessor callback, also pass the SourceRange
of expansion (for function macros it includes the right paren).

llvm-svn: 137909
2011-08-18 01:05:45 +00:00
Ted Kremenek f1c3881109 Change PreprocessingRecord::getTotalMemory() to use llvm::capacity_in_bytes().
llvm-svn: 136238
2011-07-27 18:41:20 +00:00
Ted Kremenek 182543aba2 Report more memory using in Preprocessor::getTotalMemory() and 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
2011-07-26 21:17:24 +00:00
Chris Lattner 0e62c1cc0b remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.

llvm-svn: 135852
2011-07-23 10:55:15 +00:00
Douglas Gregor 4a9c39a2f6 Rework the detailed preprocessing record to separate preprocessing
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
2011-07-21 00:47:40 +00:00
Chandler Carruth a88a221855 Move the rest of the preprocessor terminology from 'instantiate' and
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
2011-07-14 08:20:46 +00:00
Douglas Gregor 998caead70 Introduce a new libclang parsing flag,
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
2011-05-06 16:33:08 +00:00
Manuel Klimek 0c69fd2760 To be able to replay compilations we need to accurately remodel how
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
2011-04-26 21:50:03 +00:00
Chandler Carruth 3cc331a160 Add a 'RawPath' parameter to the PPCallbacks interface. This allows
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
2011-03-16 18:34:36 +00:00
Craig Silverstein 1a9ca21881 Several PPCallbacks take an SourceLocation + IdentifierInfo, rather
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
2010-11-19 21:33:15 +00:00
Douglas Gregor f09b6c9c85 Plug a leak in the preprocessing record's handling of inclusion
directives. We had a std::string in an object that was allocated via a
BumpPtrAllocator.

llvm-svn: 117912
2010-11-01 15:03:47 +00:00
Douglas Gregor 796d76a663 Extend the preprocessing record and libclang with support for
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
2010-10-20 22:00:55 +00:00
Benjamin Kramer d05f31d059 Push location through the MacroUndefined PPCallback and use it to print #undefs in -dD mode. (PR7818)
llvm-svn: 110523
2010-08-07 22:27:00 +00:00
Douglas Gregor 8aaca67b0a Robustify PreprocessingRecord slightly, by only creating macro
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
2010-03-19 21:58:23 +00:00
Douglas Gregor aae9224e49 Implement serialization and lazy deserialization of the preprocessing
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
2010-03-19 21:51:54 +00:00
Douglas Gregor 7dc8722bd3 Make the preprocessing record a PPCallbacks subclass itself,
eliminating the extra PopulatePreprocessingRecord object. This will
become useful once we start writing the preprocessing record to
precompiled headers.

llvm-svn: 98966
2010-03-19 17:12:43 +00:00
Douglas Gregor 7f6d60dcc2 Optionally store a PreprocessingRecord in the preprocessor itself, and
tie its creation to a CC1 flag -detailed-preprocessing-record.

llvm-svn: 98963
2010-03-19 16:15:56 +00:00
Douglas Gregor 78ae2481b6 Explicitly link macro instantiations to macro definitions in the
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
2010-03-18 18:23:03 +00:00
Douglas Gregor 065f8d11ca Introduce the notion of a "preprocessing record", which keeps track of
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
2010-03-18 17:52:52 +00:00