we have the ability to create a new, distict diagnostic consumer when
we go off and build a module. This avoids the currently horribleness
where the same diagnostic consumer sees diagnostics for multiple
translation units (and multiple SourceManagers!) causing all sorts of havok.
llvm-svn: 140743
a "loaded" location of the precompiled preamble.
Instead, handle specially locations of preprocessed entities:
-When looking up for preprocessed entities, map main file locations inside the
preamble range to a preamble loaded location.
-When getting the source range of a preprocessing cursor, map preamble loaded
locations back to main file locations.
Fixes rdar://10175093 & http://llvm.org/PR10999
llvm-svn: 140519
PreprocessingRecord's getPreprocessedEntitiesInRange.
Also remove all the stuff that were added in ASTUnit that are unnecessary now
that we do a binary search for preprocessed entities and deserialize only
what is necessary.
llvm-svn: 140063
check whether the requested location points inside the precompiled preamble,
in which case the returned source location will be a "loaded" one.
llvm-svn: 140060
modifying directly for the preamble.
This avoids an awful, hard to find, bug where "PreprocessorOpts.DisablePCHValidation = true"
would be persistent for subsequent reparses of the translation unit which would result
in defines, present in command-line but not in the PCH, being ignored.
Fixes rdar://9615399.
llvm-svn: 139512
The function was only counting lines that included tokens and not empty lines,
but MaxLines (mainly initiated to the line where the code-completion point resides)
is a count of overall lines (even empty ones).
llvm-svn: 139085
Preprocessor, eliminating the constructor that was used by ASTUnit
(which didn't provide an ASTContext or Prepreprocessor). Ensuring that
both objects are non-NULL will simplify module loading (but none of
that is done yet).
llvm-svn: 138986
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
and language-specific initialization. Use this to allow ASTUnit to
create a preprocessor object *before* loading the AST file. No actual
functionality change.
llvm-svn: 138983
LangOptions, rather than making distinct copies of
LangOptions. Granted, LangOptions doesn't actually get modified, but
this will eventually make it easier to construct ASTContext and
Preprocessor before we know all of the LangOptions.
llvm-svn: 138959
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
from the given source. -emit-module behaves similarly to -emit-pch,
except that Sema is somewhat more strict about the contents of
-emit-module. In the future, there are likely to be more interesting
differences.
llvm-svn: 138595
all AST files have a normal METADATA record that has the same form
regardless of whether we refer to a chained PCH or any other kind of
AST file.
Introduce the IMPORTS record, which describes all of the AST files
that are imported by this AST file, and how (as a module, a PCH file,
etc.). Currently, we emit at most one entry to this record, to support
chained PCH.
llvm-svn: 137869
already-defined and forward-declared results. Already-defined results
are fine because they could be the start of a category. Fixes
<rdar://problem/9811691>.
llvm-svn: 136559
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
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
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
clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!
llvm-svn: 134615
CompilerInvocation on the stack, because other objects (e.g., the
CompilerInstance) maintain an intrusive reference-counted pointer to
the CompilerInvocation. This doesn't matter in the normal case,
because we take back the CompilerInvocation. However, during crash
recovery, this leads to us trying to free an object on the stack, and
hilarity ensues. Fixes <rdar://problem/9652540>.
llvm-svn: 134245
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
Douglas Gregor