| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 209083
|
|
|
|
|
|
|
|
| |
libclang.
Patch by Erik Verbruggen!
llvm-svn: 196487
|
|
|
|
| |
llvm-svn: 186707
|
|
|
|
|
|
|
|
| |
MacroArgs object that provides information about
the argument tokens for a function macro.
llvm-svn: 181065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroDirective's subclasses.
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
|
|
|
|
|
|
|
|
| |
available the
full information about the macro (e.g if it was imported and where).
llvm-svn: 175978
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
|
|
|
|
|
|
|
| |
to make sure we don't crash on release if the index is not valid.
rdar://13089714
llvm-svn: 175010
|
|
|
|
|
|
|
|
| |
defined.
Patch by Enea Zaffanella!
llvm-svn: 172623
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
PreprocessingRecord and into its own class, PPConditionalDirectiveRecord.
Decoupling allows a client to use the functionality of PPConditionalDirectiveRecord
without needing a PreprocessingRecord.
llvm-svn: 169229
|
|
|
|
|
|
|
|
| |
regions
use the SourceLocation at the start of the respective region, instead of a unique integer.
llvm-svn: 169228
|
|
|
|
|
|
|
| |
loaded entities vector, otherwise its meaning will change when a module
is imported and the vector size changes.
llvm-svn: 165278
|
|
|
|
|
|
| |
resulted in an automatic module import.
llvm-svn: 165022
|
|
|
|
|
|
|
| |
an inclusion directive was automatically turned into a module import, and
PPCallbacks::moduleImport() for an explicit module import.
llvm-svn: 164874
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
* Use \p param for a parameter reference, not the (erroneous) form \arg param;
* Escape # characters in Doxygen comments as needed.
llvm-svn: 158971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 153389
|
|
|
|
|
|
|
|
|
| |
conditional directives.
Introduce PreprocessingRecord::rangeIntersectsConditionalDirective() which returns
true if a given range intersects with a conditional directive block.
llvm-svn: 152018
|
|
|
|
|
|
|
|
| |
it can only bring pain when dealing with preprocessor abuse (see: boost).
rdar://10898986
llvm-svn: 151427
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
fixes http://llvm.org/PR11120
llvm-svn: 141788
|
|
|
|
|
|
| |
may be unordered and MSVC's debug-mode doesn't like it.
llvm-svn: 140337
|
|
|
|
| |
llvm-svn: 140256
|
|
|
|
|
|
| |
return a cursor for the inner macro.
llvm-svn: 140207
|
|
|
|
|
|
| |
don't store an extra location for it.
llvm-svn: 140190
|
|
|
|
| |
llvm-svn: 140073
|
|
|
|
|
|
| |
return iterators for local, non-loaded, preprocessed entities.
llvm-svn: 140062
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
| |
for a builtin macro expansion.
llvm-svn: 139298
|
|
|
|
|
|
| |
of expansion (for function macros it includes the right paren).
llvm-svn: 137909
|
|
|
|
| |
llvm-svn: 136238
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
directives. We had a std::string in an object that was allocated via a
BumpPtrAllocator.
llvm-svn: 117912
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
#undefs in -dD mode. (PR7818)
llvm-svn: 110523
|
|
|
|
|
|
|
|
| |
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
|