| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
For PCH files, have only one open/close for temporary + rename to be safe from race conditions.
For all other output files open/close the output file directly.
Depends on llvm r136310. rdar://9082880 & http://llvm.org/PR9374.
llvm-svn: 136315
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
| |
and writer to StringRef or std::string, as appropriate.
llvm-svn: 135769
|
|
|
|
|
|
|
| |
of ASTReader so it can become its own full-fledged class
(eventually). No functionality change.
llvm-svn: 135767
|
|
|
|
|
|
| |
instead of createTemporaryFileOnDisk.
llvm-svn: 135690
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source locations from source locations loaded from an AST/PCH file.
Previously, loading an AST/PCH file involved carefully pre-allocating
space at the beginning of the source manager for the source locations
and FileIDs that correspond to the prefix, and then appending the
source locations/FileIDs used for parsing the remaining translation
unit. This design forced us into loading PCH files early, as a prefix,
whic has become a rather significant limitation.
This patch splits the SourceManager space into two parts: for source
location "addresses", the lower values (growing upward) are used to
describe parsed code, while upper values (growing downward) are used
for source locations loaded from AST/PCH files. Similarly, positive
FileIDs are used to describe parsed code while negative FileIDs are
used to file/macro locations loaded from AST/PCH files. As a result,
we can load PCH/AST files even during parsing, making various
improvemnts in the future possible, e.g., teaching #include <foo.h> to
look for and load <foo.h.gch> if it happens to be already available.
This patch was originally written by Sebastian Redl, then brought
forward to the modern age by Jonathan Turner, and finally
polished/finished by me to be committed.
llvm-svn: 135484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is switches all the interfaces points (and most of the commenst
/ local variables I saw on my way through) regarding the
NestedMacroInstantiations bit.
The libclang enums corresponding to this state were renamed, but
a legacy enum was added with the old name, and the same value to keep
existing clients working. I've added a documentation blurb for it, but
let me know if there is a canonical way to document legacy elemenst of
the libclang interface.
No functionality changed here, even in tests.
llvm-svn: 135141
|
|
|
|
|
|
|
|
|
|
|
| |
This is the only usage in clang's headers, and it's for a define
that only exists on CMake builds for the sake of the MSVC compiler,
so just use an ifdef instead.
Also add an include for config.h in a file that actually needs it,
and was picking it up by accident indirectly.
llvm-svn: 133710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are somewhat special in that they wrap any other FrontendAction,
running various ARC transformations or checks prior to the standard
action's run. To implement them easily, this extends FrontendAction to
have a WrapperFrontendAction utility class which forwards all calls by
default to an inner action setup at construction time. This is then
subclassed to override the specific behavior needed by the different
ARCMT tools.
Finally, FrontendTool is taught how to create these wrapper actions from
the existing flags and options structures.
The result is that clangFrontend no longer depends on clangARCMigrate.
This is very important, as clangARCMigrate *heavily* depends on
clangFrontend. Fundamentally ARCMigrate is at the same layer as
a library like Rewrite, sitting firmly on top of the Frontend, but tied
together with the FrontendTool when building the clang binary itself.
llvm-svn: 133161
|
|
|
|
|
|
| |
for this.
llvm-svn: 133104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 129103
|
|
|
|
| |
llvm-svn: 129095
|
|
|
|
|
|
| |
it.
llvm-svn: 129089
|
|
|
|
|
|
| |
really make any sense in this environment.
llvm-svn: 128014
|
|
|
|
|
|
|
|
|
|
| |
recovery. This was a huge resource "root" during crashes.
This change requires making a bunch of fundamental Clang structures (optionally) reference counted to allow correct
ownership semantics of these objects (e.g., ASTContext) to play out between an active ASTUnit and CompilerInstance
object.
llvm-svn: 128011
|
|
|
|
| |
llvm-svn: 127573
|
|
|
|
| |
llvm-svn: 127133
|
|
|
|
| |
llvm-svn: 126060
|
|
|
|
| |
llvm-svn: 126050
|
|
|
|
|
|
|
|
|
| |
This removes the final dependency edge from any lib outside of CodeGen
to core. As a result we can, and do, trim the dependency on core
from libclang, PrintFunctionNames, the unit tests and c-index-test.
While at it, review and trim other unneeded dependencies.
llvm-svn: 125820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overridden via remapping. Thus, when we create a "virtual" file in the
file manager, we still stat() the real file that lives behind it so
that we can provide proper uniquing based on inodes. This helps keep
the file manager much more consistent.
To take advantage of this when reparsing files in libclang, we disable
the use of the stat() cache when reparsing or performing code
completion, since the stat() cache is very likely to be out of date in
this use case.
llvm-svn: 124971
|
|
|
|
|
|
| |
information to a file.
llvm-svn: 124750
|
|
|
|
|
|
|
|
| |
callbacks class.
- Aside from being generally cleaner, this also allows -H to work correctly in
modes other than standard preprocessing (e.g., -c, -MM, etc.)
llvm-svn: 124723
|
|
|
|
|
|
| |
automatic behavior (which is undesirable in a multithreaded context).
llvm-svn: 124612
|
|
|
|
| |
llvm-svn: 123150
|
|
|
|
| |
llvm-svn: 121956
|
|
|
|
| |
llvm-svn: 121378
|
|
|
|
|
|
|
|
|
|
|
|
| |
precompiled preamble as the "main" source file's file ID within the
source manager. This makes compiling with a precompiled preamble
produce the same source locations as when compiling without the
precompiled preamble; prior to this change, we ended up with different
file IDs for source locations within the precompiled preamble
vs. those after the precompiled preamble, even for entities (e.g.,
preprocessing entities) in the same file.
llvm-svn: 120390
|
|
|
|
| |
llvm-svn: 120297
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
to simplify a bunch of code in it. It should ultimately get inlined
into FileManager.
llvm-svn: 120007
|
|
|
|
|
|
|
|
| |
VerifyDiagnosticsClient
and just check the number of errors from the DiagnosticClient.
llvm-svn: 119736
|
|
|
|
|
|
|
|
| |
keeping track
of the total number of warnings/errors reported.
llvm-svn: 119731
|
|
|
|
|
|
|
|
|
|
|
| |
-Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class.
-DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units.
-The rest of the state in Diagnostic object is considered related and tied to one translation unit.
-Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a
SourceLocation instead of a FullSourceLoc.
-Reflect the changes to various interfaces.
llvm-svn: 119730
|
|
|
|
|
|
|
|
|
|
| |
diagnostic-capturing client lives as long as the ASTUnit itself
does. Otherwise, we can end up with crashes when we get a diagnostic
outside of parsing/code completion. The circumstances under which this
happen are really hard to reproduce, because a file needs to change
from under us.
llvm-svn: 118751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 117414
|
|
|
|
|
|
|
| |
different ways. Check once, and use an assert to handle
consistency checking.
llvm-svn: 117397
|
|
|
|
|
|
| |
libclang does not support out-of-process code completion.
llvm-svn: 116253
|
|
|
|
|
|
|
|
| |
emitting diagnostics in a binary form to be consumed by libclang,
since libclang no longer does any of its work out-of-process, making
this code dead. Besides, this stuff never worked at 100% anyway.
llvm-svn: 116250
|
|
|
|
|
|
| |
argumants and to reflect actual (non-modifying) use.
llvm-svn: 116199
|
|
|
|
|
|
| |
preamble or main file. Base Decls' PCHLevel on this to make it more sane.
llvm-svn: 115626
|
|
|
|
|
|
|
|
| |
finished.
This mainly prevents failures and/or crashes when multiple processes try to read/write the same PCH file. (rdar://8392711&8294781); suggestion & review by Daniel!
llvm-svn: 114187
|
|
|
|
|
|
|
| |
the main file isn't an included file, and the IncludePos is
always SourceLocation().
llvm-svn: 112269
|
|
|
|
| |
llvm-svn: 111474
|
|
|
|
| |
llvm-svn: 111471
|
|
|
|
| |
llvm-svn: 111467
|
|
|
|
|
|
|
| |
convoluted and a bit leaky. Now, the Diagnostic object owns its
DiagnosticClient.
llvm-svn: 111437
|