Age | Commit message (Collapse) | Author |
|
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
affect the translation unit that
imports the module.
Getting diagnostic sections from modules properly working is a fixme.
rdar://13516663
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's not used anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178106 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Serialize the macro directives history into its own section
-Get rid of the macro updates section
-When de/serializing an identifier from a module, associate only one macro per
submodule that defined+exported it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dependency for PCH/modules.
When we're building a precompiled header or module against an SDK on
Darwin, there will be a file SDKSettings.plist in the sysroot. Since
stat()'ing every system header on which a module or PCH file depends
is performance suicide, we instead stat() just SDKSettings.plist. This
hack works well on Darwin; it's unclear how we want to handle this on
other platforms. If there is a canonical file, we should use it; if
not, we either have to take the performance hit of stat()'ing system
headers repeatedly or roll the dice by not checking anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177194 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.
Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.
Part of rdar://13391765
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175585 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a simpler sort, entirely automatic with the help of
llvm/utils/sort_includes.py -- no manual edits here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
allocated using the allocator associated with an ASTContext.
Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to
avoid a potential memory leak.
rdar://12761275
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The stat cache became essentially useless ever since we started
validating all file entries in the PCH.
But the motivating reason for removing it now is that it also affected
correctness in this situation:
-You have a header without include guards (using "#pragma once" or #import)
-When creating the PCH:
-The same header is referenced in an #include with different filename cases.
-In the PCH, of course, we record only one file entry for the header file
-But we cache in the PCH file the stat info for both filename cases
-Then the source files are updated and the header file is updated in a way that
its size and modification time are the same but its inode changes
-When using the PCH:
-We validate the headers, we check that header file and we create a file entry with its current inode
-There's another #include with a filename with different case than the previously created file entry
-In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode
-because of the different inodes, we think they are different files so we go ahead and include its contents.
Removing the stat cache will potentially break clients that are attempting to use the stat cache
as a way of avoiding having the actual input files available. If that use case is important, patches are welcome
to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with
literal strings, line/column computations, etc.).
This fixes rdar://5502805
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167172 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
manager block and input-file information in the control block. The
source manager entries now point back into the control block. Input
files are now lazily deserialized (if validation is disabled). Reduces
Cocoa's PCH by the ~70k I added when I introduced the redundancy in
r166251.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166429 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
block, so the input files are validated early on, before we've
committed to loading the AST file. This (accidentally) fixed a but
wherein the main file used to generate the AST file would *not* be
validated by the existing validation logic.
At the moment, this leads to some duplication of filenames between the
source manager block and input-file blocks, as well as validation
logic. This will be handled via an upcoming patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
block, which stores information about how the AST file to generated,
from the AST block, which stores the actual serialized AST. The
information in the control block should be enough to determine whether
the AST file is up-to-date and compatible with the current translation
unit, and reading it should not cause any side effects that aren't
easy to undo. That way, we can back out from an attempt to read an
incompatible or out-of-date AST file.
Note that there is still more factoring to do. In particular,
information about the source files used to generate the AST file
(along with their time stamps, sizes, etc.) still resides in the
source manager block.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166166 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is no longer necessary, as well as the little bit of infrastructure in
the AST writer that used it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MacroInfo*. Instead of simply dumping an offset into the current file,
give each macro definition a proper ID with all of the standard
modules-remapping facilities. Additionally, when a macro is modified
in a subsequent AST file (e.g., #undef'ing a macro loaded from another
module or from a precompiled header), provide a macro update record
rather than rewriting the entire macro definition. This gives us
greater consistency with the way we handle declarations, and ties
together macro definitions much more cleanly.
Note that we're still not actually deserializing macro history (we
never were), but it's far easy to do properly now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165560 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as key instead of a SLocEntry pointer. This allows the array of
file sorted declarations in a PCH/module to be deterministic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165047 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
coming from an AST file are registered for serialization.
A static data member instantiation of in a chained PCH could be missed
when serializing decls; the result was that when emitting the visible decls
map of its DeclContext, we would use a DeclID that was not actually emitted,
leading to crashes or hangs.
Fix this by making sure such decls are always registered for serialization.
Also introduce extra sanity checks to make sure we don't register new
declarations or types after we have serialized the types/decls block.
rdar://11728990
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159550 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Part of rdar://11353109.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
attached. Since we do not support any attributes which appertain to a statement
(yet), testing of this is necessarily quite minimal.
Patch by Alexander Kornienko!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compiler errors or not.
-Control whether ASTReader should reject such a PCH by a boolean flag at ASTReader's creation time.
By default, such a PCH file will be rejected with an error when trying to load it.
[libclang] Allow clang_saveTranslationUnit to create a PCH file even if compiler errors
occurred.
-Have libclang API calls accept a PCH that had compiler errors.
The general idea is that we want libclang to stay functional even if a PCH had a compiler error.
rdar://10976363.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152192 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ctor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- This reduces our total # of allocations building a PCH for Cocoa.h by almost
a whopping 50%.
- A SmallPtrMap would be cleaner, but since we don't have one yet...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151697 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operator overloads out of line.
This seems to negatively affect compile time onsome ObjC tests
(which use a lot of partial diagnostics I assume). I have to come
up with a way to keep them inline without including Diagnostic.h
everywhere. Now adding a new diagnostic requires a full rebuild
of e.g. the static analyzer which doesn't even use those diagnostics.
This reverts commit 6496bd10dc3a6d5e3266348f08b6e35f8184bc99.
This reverts commit 7af19b817ba964ac560b50c1ed6183235f699789.
This reverts commit fdd15602a42bbe26185978ef1e17019f6d969aa7.
This reverts commit 00bd44d5677783527d7517c1ffe45e4d75a0f56f.
This reverts commit ef9b60ffed980864a8db26ad30344be429e58ff5.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150006 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the direct serialization of the linked-list structure. Instead, use a
scheme similar to how we handle redeclarations, with redeclaration
lists on the side. This addresses several issues:
- In cases involving mixing and matching of many categories across
many modules, the linked-list structure would not be consistent
across different modules, and categories would get lost.
- If a module is loaded after the class definition and its other
categories have already been loaded, we wouldn't see any categories
in the newly-loaded module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
protocol, record the definition pointer in the canonical declaration
for that entity, and then propagate that definition pointer from the
canonical declaration to all other deserialized declarations. This
approach works well even when deserializing declarations that didn't
know about the original definition, which can occur with modules.
A nice bonus from this definition-deserialization approach is that we
no longer need update records when a definition is added, because the
redeclaration chains ensure that the if any declaration is loaded, the
definition will also get loaded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148223 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
chains, again. The prior implementation was very linked-list oriented, and
the list-splicing logic was both fairly convoluted (when loading from
multiple modules) and failed to preserve a reasonable ordering for the
redeclaration chains.
This new implementation uses a simpler strategy, where we store the
ordered redeclaration chains in an array-like structure (indexed based
on the first declaration), and use that ordering to add individual
deserialized declarations to the end of the existing chain. That way,
the chain mimics the ordering from its modules, and a bug somewhere is
far less likely to result in a broken linked list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148222 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
each deserialized declaration, since that information is already
available in each declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147619 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
longer needed now that we aren't back-patching ObjCProtocolDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
set of (previously-canonical) declaration IDs to the module file, so
that future AST reader instances that load the module know which
declarations are merged. This is important in the fairly tricky case
where a declaration of an entity, e.g.,
@class X;
occurs before the import of a module that also declares that
entity. We merge the declarations, and record the fact that the
declaration of X loaded from the module was merged into the (now
canonical) declaration of X that we parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147181 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146994 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed).
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implicitly generates submodules corresponding to the headers that fall
within a module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when deserialized, fixing random crashes in libclang.
Also simplifies how OpaqueValueExprs are [de]serialized.
The reader/writer automatically retains pointer equality of sub-statements (when a
statement node is referenced in multiple nodes), so no need to manually handle it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(sub)module is read from an AST file. This makes sure that the AST
writer knows how to map all modules to their global IDs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145685 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
only the macro definitions from visible (sub)modules will actually be
visible. This provides the same behavior for macros that r145640
provided for declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of that declaration, and encode the submodule ID in each declaration
stored in an AST file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145555 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a standard global/local scheme, so that submodule definitions will
eventually be able to refer to submodules in other top-level
modules. We'll need this functionality soonish.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145549 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
submodules. This information will eventually be used for name hiding
when dealing with submodules. For now, we only use it to ensure that
the module "key" returned when loading a module will always be a
module (rather than occasionally being a FileEntry).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
writer. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145479 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
introduces/redeclares a property.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144520 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
should have been already emitted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
HeaderFileInfos
from the primary PCH is deserialized, otherwise we lose info that headers were
already #imported/#included.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144510 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
[is/set]ChangedSinceDeserialization
and remove them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of its categories because
it is going to be rewritten (and the chain will be serialized again), otherwise we may form a cycle in its
categories list when deserializing.
Also introduce ASTMutationListener::CompletedObjCForwardRef to notify that a forward reference
was completed; using Decl's isChangedSinceDeserialization/setChangedSinceDeserialization
is bug inducing and kinda gross, we should phase it out.
Fixes infinite loop in rdar://10418538.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144465 91177308-0d34-0410-b5e6-96231b3b80d8
|