| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
its own header and giving it some more structure. No
functionality change.
llvm-svn: 120030
|
|
|
|
|
|
| |
client should just pass in absolute paths.
llvm-svn: 120012
|
|
|
|
|
|
|
|
|
| |
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
llvm-svn: 120010
|
|
|
|
| |
llvm-svn: 119996
|
|
|
|
| |
llvm-svn: 119935
|
|
|
|
|
|
|
|
|
|
| |
expands to nothing"
and use a better and more general approach, where NullStmt has a flag to indicate whether it was preceded by an empty macro.
Thanks to Abramo Bagnara for the hint!
llvm-svn: 119887
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
if (condition)
CALL(0); // empty macro but don't warn for empty body.
Fixes rdar://8436021.
llvm-svn: 119838
|
|
|
|
|
|
| |
related to.
llvm-svn: 119479
|
|
|
|
|
|
| |
possible to create one without a preprocessor.
llvm-svn: 119476
|
|
|
|
| |
llvm-svn: 119475
|
|
|
|
|
|
| |
Preprocessor to Lexer where they make more sense.
llvm-svn: 119474
|
|
|
|
| |
llvm-svn: 119472
|
|
|
|
| |
llvm-svn: 119471
|
|
|
|
| |
llvm-svn: 119470
|
|
|
|
| |
llvm-svn: 119469
|
|
|
|
|
|
| |
pushing the dependency on the preprocessor out a bit.
llvm-svn: 119468
|
|
|
|
|
|
|
| |
SourceManager::getPresumedLoc(), so that we don't try to make use of
an invalid presumed location. Doing so can cause crashes.
llvm-svn: 118885
|
|
|
|
|
|
| |
Confirmed on MSVS10.
llvm-svn: 118496
|
|
|
|
| |
llvm-svn: 118493
|
|
|
|
| |
llvm-svn: 118487
|
|
|
|
| |
llvm-svn: 118478
|
|
|
|
|
|
|
| |
tweak the documentation for deprecation-with-message. Provide __has_feature
tests for both. rdar://problem/8605692
llvm-svn: 118435
|
|
|
|
|
|
|
|
|
|
|
| |
The callback info for #if/#elif is not great -- ideally it would give
us a list of tokens in the #if, or even better, a little parse tree.
But that's a lot more work. Instead, clients can retokenize using
Lexer::LexFromRawLexer().
Reviewed by nlewycky.
llvm-svn: 118318
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
llvm-svn: 118203
|
|
|
|
|
|
|
| |
directives. We had a std::string in an object that was allocated via a
BumpPtrAllocator.
llvm-svn: 117912
|
|
|
|
|
|
| |
PR8423
llvm-svn: 117775
|
|
|
|
|
|
|
|
|
| |
load identifiers without loading their corresponding macro
definitions. This is likely to improve PCH performance slightly, and
reduces deserialization stack depth considerably when using
preprocessor metaprogramming.
llvm-svn: 117750
|
|
|
|
| |
llvm-svn: 117204
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
__has_builtin.
llvm-svn: 116906
|
|
|
|
|
|
|
|
|
| |
Now MICache is a linked list (per the FIXME), where we tradeoff between MacroInfo objects being in MICache
and MIChainHead. MacroInfo objects in the MICache chain are already "Destroy()'ed", so they can be reused. When
inserting into MICache, we need to remove them from the regular linked list so that they aren't destroyed more than
once.
llvm-svn: 116869
|
|
|
|
|
|
| |
Preprocessor.
llvm-svn: 116864
|
|
|
|
|
|
|
|
|
| |
The problem was not the management of MacroInfo objects, but that when we recycle them
via the MICache the memory of the underlying SmallVector (within MacroInfo) was not getting
released. This is because objects stashed into MICache simply are reused with a placement
new, and never have their destructor called.
llvm-svn: 116862
|
|
|
|
| |
llvm-svn: 116861
|
|
|
|
|
|
|
|
|
|
|
|
| |
the Preprocessor maintain them in a linked
list of allocated MacroInfos. This requires only 1 extra pointer per MacroInfo object, and allows us to blow them
away in one place. This fixes an elusive memory leak with MacroInfos (whose exact location I couldn't still figure
out despite substantial digging).
Fixes <rdar://problem/8361834>.
llvm-svn: 116842
|
|
|
|
|
|
|
|
| |
"#pragma push_macro" uses. This
fixes a potential memory leak.
llvm-svn: 116826
|
|
|
|
| |
llvm-svn: 116825
|
|
|
|
|
|
| |
by Martin Vejnar!
llvm-svn: 116460
|
|
|
|
|
|
| |
into APInt.
llvm-svn: 116453
|
|
|
|
| |
llvm-svn: 116129
|
|
|
|
|
|
| |
bit by me).
llvm-svn: 116122
|
|
|
|
| |
llvm-svn: 115743
|
|
|
|
|
|
|
|
|
|
| |
auto f(int) -> int
from Daniel Wallin!
(With a few minor bug fixes from me).
llvm-svn: 115322
|
|
|
|
|
|
| |
start of the buffer, or we risk overflow.
llvm-svn: 115117
|
|
|
|
|
|
| |
That, and keep aKor happy :P.
llvm-svn: 114816
|
|
|
|
| |
llvm-svn: 114814
|
|
|
|
| |
llvm-svn: 114762
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead"
This reverts commit r113631
Conflicts:
CMakeLists.txt
lib/CodeGen/CMakeLists.txt
llvm-svn: 113817
|
|
|
|
|
|
| |
of whatever we were using before...
llvm-svn: 113631
|