| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
forward declarations and definitions of an Objective-C protocol are
represented within a single chain of ObjCProtocolDecls.
llvm-svn: 147412
|
|
|
|
|
|
|
|
|
| |
features needed for a particular module to be available. This allows
mixed-language modules, where certain headers only work under some
language variants (e.g., in C++, std.tuple might only be available in
C++11 mode).
llvm-svn: 147387
|
|
|
|
|
|
|
|
| |
found within that umbrella directory that were not actually included
by the umbrella header. They should either be referenced in the module
map or included by the umbrella header.
llvm-svn: 147207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 147181
|
|
|
|
|
|
|
| |
class that comes from a different module file, make sure that we load
all of the pending declarations for the original declaration.
llvm-svn: 147168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration of that same class that either came from some other module
or occurred in the translation unit loading the module. In this case,
we need to merge the two redeclaration chains immediately so that all
such declarations have the same canonical declaration in the resulting
AST (even though they don't in the module files we've imported).
Focusing on Objective-C classes until I'm happy with the design, then
I'll both (1) extend this notion to other kinds of declarations, and
(2) optimize away this extra checking when we're not dealing with
modules. For now, doing this checking for PCH files/preambles gives us
better testing coverage.
llvm-svn: 147123
|
|
|
|
|
|
|
| |
notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.
llvm-svn: 146994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
llvm-svn: 146980
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.
Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.
llvm-svn: 146933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
redeclaration templates (RedeclarableTemplateDecl), similarly to the
way (de-)serialization is implemented for Redeclarable<T>. In the
process, found a simpler formulation for handling redeclaration
chains and implemented that in both places.
The new test establishes that we're building the redeclaration chains
properly. However, the FIXME indicates where we're tickling a
different bug that has to do with us not setting the DefinitionData
pointer properly in redeclarations that we detected after the
definition itself was deserialized. The (separable) fix for that bug
is forthcoming.
llvm-svn: 146883
|
|
|
|
|
|
|
|
|
|
| |
imported modules that don't introduce any new entities of a particular
kind. Allow these entries to be replaced with entries for another
loaded module.
In the included test case, selectors exhibit this behavior.
llvm-svn: 146870
|
|
|
|
|
|
|
|
|
|
|
| |
which there are no redeclarations. This reduced by size of the PCH
file for Cocoa.h by ~650k: ~536k of that was in the new
LOCAL_REDECLARATIONS table, which went from a ridiculous 540k down to
an acceptable 3.5k, while the rest was due to the more compact
abbreviated representation of redeclarable declaration kinds (which no
longer need to store the 'first' declaration ID).
llvm-svn: 146869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146841
|
|
|
|
| |
llvm-svn: 146722
|
|
|
|
|
|
|
| |
is not visible, look for any previous declarations of that entity that
might be visible.
llvm-svn: 146563
|
|
|
|
|
|
| |
the subdirectories to find headers in submodules.
llvm-svn: 146398
|
|
|
|
|
|
|
| |
actually a terribly good heuristic, and the world is too horrible for
it to work.
llvm-svn: 146393
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all of the headers below that particular directory. Use umbrella
directories as a clean way to deal with (1) directories/frameworks
that don't have an umbrella header, but don't want to enumerate all of
their headers, and (2) PrivateHeaders, which we never want to
enumerate and want to keep separate from the main umbrella header.
This also eliminates a little more of the "magic" for private headers,
and frameworks in general.
llvm-svn: 146235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
part of the module with that umbrella directory. However, unlike
umbrella headers, which are expected to include all of the headers
within their subdirectories, Clang will automatically include all of
the headers it finds in the named subdirectory.
The intent here is to allow a module map to trivially turn a
subdirectory into a module, where the module's structure can mimic the
directory structure.
llvm-svn: 146165
|
|
|
|
|
|
|
|
|
|
|
| |
a modifier for a header declarartion, e.g.,
umbrella header "headername"
Collapse the umbrella-handling code in the parser into the
header-handling code, so we don't duplicate the header-search logic.
llvm-svn: 146159
|
|
|
|
|
|
|
| |
that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.
llvm-svn: 146156
|
|
|
|
|
|
| |
private headers in a framework.
llvm-svn: 146082
|
|
|
|
|
|
|
|
|
| |
when we load a module map (module.map) from a directory, also load a
private module map (module_private.map) for that directory, if
present. That private module map can inject a new submodule that
captures private headers.
llvm-svn: 146012
|
|
|
|
|
|
| |
modules for each of its subframeworks.
llvm-svn: 145957
|
|
|
|
| |
llvm-svn: 145945
|
|
|
|
|
|
|
|
| |
frameworks). A submodule can now be labeled as a "framework", and
header search will look into the appropriate Headers/PrivateHeaders
subdirectories for named headers.
llvm-svn: 145941
|
|
|
|
|
|
|
| |
implicitly generates submodules corresponding to the headers that fall
within a module.
llvm-svn: 145887
|
|
|
|
|
|
|
| |
Module, and (de-)serialize this information. Semantics of inferred
submodules to follow.
llvm-svn: 145864
|
|
|
|
|
|
| |
(i.e., 'export *'), to better match the semantics of headers.
llvm-svn: 145813
|
|
|
|
|
|
|
|
| |
to re-export anything that it imports. This opt-in feature makes a
module behave more like a header, because it can be used to re-export
the transitive closure of a (sub)module's dependencies.
llvm-svn: 145811
|
|
|
|
| |
llvm-svn: 145710
|
|
|
|
| |
llvm-svn: 145700
|
|
|
|
|
|
|
|
| |
only the macro definitions from visible (sub)modules will actually be
visible. This provides the same behavior for macros that r145640
provided for declarations.
llvm-svn: 145683
|
|
|
|
|
|
|
|
| |
within module maps, which will (eventually) be used to re-export a
module from another module. There are still some pieces missing,
however.
llvm-svn: 145665
|
|
|
|
|
|
| |
module. When that module becomes visible, so do those declarations.
llvm-svn: 145640
|
|
|
|
|
|
| |
an #include/#import as a module import.
llvm-svn: 145500
|
|
|
|
|
|
|
|
|
| |
check whether the named submodules themselves are actually
valid, and drill down to the named submodule (although we don't do
anything with it yet). Perform typo correction on the submodule names
when possible.
llvm-svn: 145477
|
|
|
|
|
|
|
| |
modules (obviously) describe frameworks, and understand the header
layout of frameworks.
llvm-svn: 144921
|
|
|
|
| |
llvm-svn: 144862
|
|
|
|
|
|
|
|
| |
the umbrella header's directory and its subdirectories are part of the
module (that's why it's an umbrella). Make sure that these headers are
considered to be part of the module for lookup purposes.
llvm-svn: 144859
|
|
|
|
| |
llvm-svn: 144795
|
|
|
|
| |
llvm-svn: 144779
|
|
|
|
|
|
| |
and remove stray fprintf.
llvm-svn: 144742
|
|
|
|
|
|
|
| |
interface. This is currently limited to modules with umbrella
headers.
llvm-svn: 144736
|
|
|
|
|
|
|
|
| |
into a submodule. Submodules aren't actually supported anywhere else,
but we do parse them, so this verifies that we're at least seeing
through them properly.
llvm-svn: 144436
|
|
|
|
|
|
|
|
| |
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same name as the
module we're looking for.
llvm-svn: 144433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
map, so long as they have an umbrella header. This makes it possible
to introduce a module map + umbrella header for a given set of
headers, to turn it into a module.
There are two major deficiencies here: first, we don't go hunting for
module map files when we just see a module import (so we won't know
about the modules described therein). Second, we don't yet have a way
to build modules that don't have umbrella headers, or have incomplete
umbrella headers.
llvm-svn: 144424
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Module map files provide a way to map between headers and modules, so
that we can layer a module system on top of existing headers without
changing those headers at all.
This commit introduces the module map file parser and the module map
that it generates, and wires up the module map file parser so that
we'll automatically find module map files as part of header
search. Note that we don't yet use the information stored in the
module map.
llvm-svn: 144402
|
|
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
|
|
|
|
|
|
|
|
| |
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.
llvm-svn: 142187
|