consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
llvm-svn: 172665
will have a shared library with the same name as its framework (and no
suffix!) within its .framework directory. Detect this both when
inferring the whole top-level framework and when parsing a module map.
llvm-svn: 172439
metadata for linking against the libraries/frameworks for imported
modules.
The module map language is extended with a new "link" directive that
specifies what library or framework to link against when a module is
imported, e.g.,
link "clangAST"
or
link framework "MyFramework"
Importing the corresponding module (or any of its submodules) will
eventually link against the named library/framework.
For now, I've added some placeholder global metadata that encodes the
imported libraries/frameworks, so that we can test that this
information gets through to the IR. The format of the data is still
under discussion.
llvm-svn: 172437
(because they are part of some module) but have not been made visible
(because they are in a submodule that wasn't imported), filter out
those declarations unless both the old declaration and the new
declaration have external linkage. When one or both has internal
linkage, there should be no conflict unless both are imported.
llvm-svn: 171925
allowing a module map to be placed one level above the '.framework'
directories to specify that all .frameworks within that directory can
be inferred as framework modules. One can also specifically exclude
frameworks known not to work.
This makes explicit (and more restricted) behavior modules have had
"forever", where *any* .framework was assumed to be able to be built
as a module. That's not necessarily true, so we white-list directories
(with exclusions) when those directories have been audited.
llvm-svn: 167482
token. This is important because the first token could actually be
after an #include that triggers a module import, which might use
either Sema or the AST consumer before it would have been initialized.
llvm-svn: 167423
description. Previously, one could emulate this behavior by placing
the header in an always-unavailable submodule, but Argyrios guilted me
into expressing this idea properly.
llvm-svn: 165921
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
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.
llvm-svn: 165560
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
llvm-svn: 165513
This is especially relevant for templatedDecls that might be injected (and thus have their DeclContext set to) somewhere completely different.
llvm-svn: 165005
Check whether a pending instantiation needs to be instantiated (or whether an instantiation already exists).
Verify the size of the PendingInstantiations record (was only checking size of existing PendingInstantiations).
Migrate Obj-C++ part of redecl-merge into separate test, now that this is growing.
templates.mm: test that CodeGen has seen exactly one definition of template instantiations.
redecl-merge.m: use "@" specifier for expected-diagnostics.
llvm-svn: 164993
Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.
llvm-svn: 164932
specific module (__building_module(modulename)) and to get the name of
the current module as an identifier (__MODULE__).
Used to help headers behave differently when they're being included as
part of building a module. Oh, the irony.
llvm-svn: 164605
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
llvm-svn: 161650
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
llvm-svn: 160068
turns out that it's actually needed for C++ modules support. Since simplifying
it didn't cause any test failures, I'll add a test for it.
llvm-svn: 154582
into using non-absolute system includes (<foo>)...
... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.
As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.
llvm-svn: 149611
single attribute ("system") that allows us to mark a module as being a
"system" module. Each of the headers that makes up a system module is
considered to be a system header, so that we (for example) suppress
warnings there.
If a module is being inferred for a framework, and that framework
directory is within a system frameworks directory, infer it as a
system framework.
llvm-svn: 149143
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.
llvm-svn: 149112
additional data from the external Sema source. This properly copes
with modules that are imported after we have already searched in the
global method pool for a given selector. For PCH, it's a slight
pessimization to be fixed soon.
llvm-svn: 148891
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.
llvm-svn: 148223
the anonymous namespace to its parent. Semantically, this means that
the anonymous namespaces defined in one module are distinct from the
anonymous namespaces defined in another module.
llvm-svn: 147782
modules. Teach name lookup into namespaces to search in each of the
merged DeclContexts as well as the (now-primary) DeclContext. This
supports the common case where two different modules put something
into the same namespace.
llvm-svn: 147778
to Redeclarable<NamespaceDecl>, so that we benefit from the improveed
redeclaration deserialization and merging logic provided by
Redeclarable<T>. Otherwise, no functionality change.
As a drive-by fix, collapse the "inline" bit into the low bit of the
original namespace/anonymous namespace, saving 8 bytes per
NamespaceDecl on x86_64.
llvm-svn: 147729
include stack to find the first file that is known to be part of the
module. This copes with situations where the module map doesn't
completely specify all of the headers that are involved in the module,
which can come up when there are very strange #include_next chains
(e.g., with weird compiler/stdlib headers like stdarg.h or float.h).
llvm-svn: 147662
to see hidden declarations because every tag lookup is effectively a
redeclaration lookup. For example, image that
struct foo;
is declared in a submodule that is known but hasn't been imported. If
someone later writes
struct foo *foo_p;
then "struct foo" is either a reference or a redeclaration. To keep
the redeclaration chains sound, we treat it like a redeclaration for
name-lookup purposes.
llvm-svn: 147588
different modules. This implementation is a first approximation of
what we want, using only the function type to determine
equivalence. Later, we'll want to deal with some of the more subtle
issues, including:
- C allows a prototyped declaration and a non-prototyped declaration
to be merged, which we should support
- We may want to ignore the return type when merging, then
complain if the return types differ. Or, we may want to leave it
as it us, so that we only complain if overload resolution
eventually fails.
- C++ non-static member functions need to consider cv-qualifiers
and ref-qualifiers.
- Function templates need to consider the template parameters and
return type.
- Function template specializations will have special rules.
- We can now (accidentally!) end up overloading in C, even without
the "overloadable" attribute, and will need to detect this at some
point.
The actual detection of "is this an overload?" is implemented by
Sema::IsOverload(), which will need to be moved into the AST library
for re-use here. That will be a future refactor.
llvm-svn: 147534
the AST reader doesn't actually perform a merge, because name lookup
knows how to merge identical typedefs together.
As part of this, teach C/Objective-C name lookup to return multiple
results in all cases, rather than first digging through the attributes
to see if the value is overloadable. This way, we'll catch ambiguous
lookups in C/Objective-C.
llvm-svn: 147498
Douglas Gregor