| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
so that we use ID zero as a sentinel for "no result". This matches the
convention set by all of the other global IDs.
llvm-svn: 136885
|
|
|
|
|
|
| |
the detailed preprocessing record. Tested with the standard "gaps" method.
llvm-svn: 136882
|
|
|
|
| |
llvm-svn: 136879
|
|
|
|
|
|
|
|
| |
IDs will never cross module boundaries, since they're tied to the
CXXDefinitionData, so just use a local mapping throughout. Eliminate
the global -> local tables and supporting data.
llvm-svn: 136847
|
|
|
|
|
|
| |
reader. Tested with the usual "gaps" method.
llvm-svn: 136839
|
|
|
|
|
|
|
| |
reader, and fix up the one (!) place where we were improperly mapping
a local ID to a global ID. Tested via the usual "gaps" trick.
llvm-svn: 136817
|
|
|
|
| |
llvm-svn: 136792
|
|
|
|
|
|
|
|
| |
AST file, along with an enumeration naming those predefined
declarations. No functionality change, but this will make it easier to
introduce new predefined declarations, when/if we need them.
llvm-svn: 136781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reader, to allow AST files to be loaded with their declarations
remapped to different ID numbers. Fix a number of places where we were
either failing to map local declaration IDs into global declaration
IDs or where interpreting the local declaration IDs within the wrong
module.
I've tested this via the usual "random gaps" method. It works well
except for the preamble tests, because our handling of the precompiled
preamble requires declaration and preprocessed entity to be stable
when parsing code and then loading that back into memory. This
property will hold in general, but my randomized testing naturally
breaks this property to get more coverage. In the future, I expect
that the precompiled preamble logic won't need this property.
I am very unhappy with the current handling of the translation unit,
which is a rather egregious hack. We're going to have to do something
very different here for loading multiple AST files, because we don't
want to have to cope with merging two translation units. Likely, we'll
just handle translation units entirely via "update" records, and
predefine a single, fixed declaration ID for the translation
unit. That will come later.
llvm-svn: 136779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by eliminating the type ID from constructor, destructor, and
conversion function names. There are several reasons for this change:
- A given type (say, int*) isn't guaranteed to have a single, unique
type ID within a chain of PCH files. Hence, we could end up hashing
based on the wrong type ID, causing name lookup to fail.
- The mapping from types back to type IDs required one DenseMap
entry for every type that was ever deserialized, which was an
unacceptable cost to support just the name lookup of constructors,
destructors, and conversion functions. Plus, this mapping could
never actually work with chained or multiple PCH, based on the first
bullet.
Once we have eliminated the type from the hash function, these
problems go away, as does my horrible "reverse type remap" hack, which
was doomed from the start (see bullet #1 above) and far too
complicated.
However, note that removing the type from the hash function means that
all constructors, destructors, and conversion functions have the same
hash key, so I've updated the caller to double-check that the
declarations found have the appropriate name.
llvm-svn: 136708
|
|
|
|
|
|
| |
the virtual files the ASTReader has to handle. Specifically, this occurs when the reader is reading AST files that were created in memory and not written to disk. For example, when a user creates a chained PCH using command line flags. These virtual files are stored in MemoryBuffers in ChainIncludeSource.cpp, and then read back in by the ASTReader. This patch moves the management of these buffers into the ModuleManager, so that it becomes the authority on where these buffers are located.
llvm-svn: 136697
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reader. This scheme permits an AST file to be loaded with its type IDs
shifted anywhere in the type ID space.
At present, the type indices are still allocated in the same boring
way they always have been, just by adding up the number of types in
each PCH file within the chain. However, I've done testing with this
patch by randomly sliding the base indices at load time, to ensure
that remapping is occurring as expected. I may eventually formalize
this in some testing flag, but loading multiple (non-chained) AST
files at once will eventually exercise the same code.
There is one known problem with this patch, which involves name lookup
of operator names (e.g., "x.operator int*()") in cases where multiple
PCH files in the chain. The hash function itself depends on having a
stable type ID, which doesn't happen with chained PCH and *certainly*
doesn't happen when sliding type IDs around. We'll need another
approach. I'll tackle that next.
llvm-svn: 136693
|
|
|
|
|
|
|
|
| |
reader statistics), to show the local-to-global mappings. The only
such mapping we have (at least, for now) is for source location
offsets.
llvm-svn: 136687
|
|
|
|
|
|
|
|
| |
all of the kinds of IDs that can be offset. No effectively
functionality change; this is preparation for adding remapping for
IDs.
llvm-svn: 136686
|
|
|
|
|
|
| |
the greater role it will soon play in remapping.
llvm-svn: 136619
|
|
|
|
|
|
| |
set to represent the modules a module imports.
llvm-svn: 136476
|
|
|
|
| |
llvm-svn: 136442
|
|
|
|
|
|
|
|
|
| |
were (Module*, Offset) with equivalent maps whose value type is just a
Module*. The offsets have moved into corresponding "Base" fields
within the Module itself, where they will also be helpful for
local->global translation (eventually).
llvm-svn: 136441
|
|
|
|
|
|
|
| |
Module itself, which makes more sense. This pattern to be repeated
several more times.
llvm-svn: 136436
|
|
|
|
|
|
| |
is source-order. Also, removing unused NextInSource field of Module.
llvm-svn: 136423
|
|
|
|
|
|
|
| |
it appropriately. Also, patch up a place where we were failing to map
local macro definition IDs into global macro definition IDs.
llvm-svn: 136411
|
|
|
|
| |
llvm-svn: 136410
|
|
|
|
|
|
| |
consistently in the ASTReader.
llvm-svn: 136395
|
|
|
|
|
|
| |
IDs properly, although the mapping itself is still trivial.
llvm-svn: 136391
|
|
|
|
|
|
|
|
| |
point, ASTReader::InitializeSema() has very little interesting work,
*except* issues stemming from preloaded declarations. That's something
we'll still need to cope with.
llvm-svn: 136378
|
|
|
|
|
|
|
| |
Module member to being an ASTReader member; we want it to be
centralized for lazy deserialization.
llvm-svn: 136373
|
|
|
|
|
|
|
|
| |
completely broken deserialization mapping code we had for VTableUses,
which would have broken horribly as soon as our local-to-global ID
mapping became interesting.
llvm-svn: 136371
|
|
|
|
| |
llvm-svn: 136368
|
|
|
|
|
|
| |
of its lookup instead of the filename. This is a more correct unique identifier, as symlinks can be handled by the FileManager.
llvm-svn: 136363
|
|
|
|
| |
llvm-svn: 136357
|
|
|
|
|
|
|
| |
that it accumulates referenced selectors from each of the modules/PCH
files as they are loaded. No actual functionality change, yet.
llvm-svn: 136356
|
|
|
|
|
|
|
|
|
| |
we could turn this into an on-disk hash table so we don't load the
whole thing the first time we need it. However, it tends to be very,
very small (i.e., empty) for most precompiled headers, so it isn't all
that interesting.
llvm-svn: 136352
|
|
|
|
|
|
| |
fields of HeaderFileInfo.
llvm-svn: 136332
|
|
|
|
| |
llvm-svn: 136318
|
|
|
|
| |
llvm-svn: 136317
|
|
|
|
| |
llvm-svn: 136314
|
|
|
|
| |
llvm-svn: 136273
|
|
|
|
|
|
|
|
|
| |
- Added LazyVector::erase() to support this use case.
- Factored out the LazyDecl-of-Decls to RecordData translation in
the ASTWriter. There is still a pile of code duplication here to
eliminate.
llvm-svn: 136270
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contents are lazily loaded on demand from an external source (e.g., an
ExternalASTSource or ExternalSemaSource). The "loaded" entities are
kept separate from the "local" entities, so that the two can grow
independently.
Switch Sema::TentativeDefinitions from a normal vector that is eagerly
populated by the ASTReader into one of these LazyVectors, making the
ASTReader a bit more like me (i.e., lazy).
llvm-svn: 136262
|
|
|
|
| |
llvm-svn: 136224
|
|
|
|
|
|
| |
functionality, like lookup-by-name and exporting lookup tables, into the module manager. Methods now have documentation. A few more functions have been switched over to the new iterator style and away from manual/explicit iteration. Ultimately we want to move away from name lookup here, as symlinks make filenames not a safe unique value, but we use it here as a stopgap before better measures are in place (namely instead using FileEntry* from a global FileManager).
llvm-svn: 136107
|
|
|
|
| |
llvm-svn: 136054
|
|
|
|
|
|
| |
a chain of AST files, instead redirect calls through a module manager. This should help move toward a DAG and the potential of loading multiple, unrelated PCH files. It's still early in development.
llvm-svn: 135957
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
| |
llvm-svn: 135775
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so that we have one, simple way to map from global bit offsets to
local bit offsets. Eliminates a number of loops over the chain, and
generalizes for more interesting bit remappings.
Also, as an amusing oddity, we were computing global bit offsets
*backwards* for preprocessed entities (e.g., the directly included PCH
file in the chain would start at offset zero, rather than the original
PCH that occurs first in translation unit). Even more amusingly, it
made precompiled preambles work, because we were forgetting to adjust
the local bit offset to a global bit offset when storing preprocessed
entity offsets in the ASTUnit. Two wrongs made a right, and now
they're both right.
llvm-svn: 135750
|
|
|
|
|
|
|
|
| |
type IDs into a single place, and make sure that all of the callers
use the appropriate functions to do the mapping. Since the mapping is
still the identity function, this is essentially a no-op.
llvm-svn: 135733
|
|
|
|
|
|
| |
within the ASTReader (I hope).
llvm-svn: 135720
|