headers even if they arrived when merging non-system modules.
The idea of this code is that we don't want to warn the user about
macros defined multiple times by their system headers with slightly
different definitions. We should have this behavior if either the
macro comes from a system module, or the definition within the module
comes from a system header. Previously, we would warn on ambiguous
macros being merged when they came from a users modules even though they
only showed up via system headers.
By surviving this we can handle common system header macro differences
like differing 'const' qualification of pointers due to some headers
predating 'const' being valid in C code, even when those systems headers
are pre-built into a system module.
Differential Revision: http://reviews.llvm.org/D8310
llvm-svn: 232149
definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).
One-line fix by me; reduced testcase by Daniel Jasper!
llvm-svn: 231950
specification, update all prior declarations if the new one has an explicit
exception specification and the prior ones don't.
Patch by Vassil Vassilev! Some minor tweaking and test case by me.
llvm-svn: 231738
move the operator delete updating into a separate update record so we can cope
with updating another module's destructor's operator delete.
llvm-svn: 231735
one can give us more lookup results (due to implicit special members). Be sure
to complete the redecl chain for every kind of DeclContext before performing a
lookup into it, rather than only doing so for NamespaceDecls.
llvm-svn: 230558
This would cause frameworks to have spurious "redefinition" errors if
they had both a (legacy) "module.map" and a (new) "module.modulemap" file and we
happened to do a sub-directory search in that directory using a
non-framework include path (e.g. -Ifoo/ -Ffoo/). For migration
purposes it's very handy that the compiler will prefer the new spelling
of the filename and not look at the old one if it doesn't need to.
llvm-svn: 230308
bug is not actually modules-specific, but it's a little tricky to tickle it
outside of modules builds, so submitting with the reduced testcase I have.
llvm-svn: 230303
If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
llvm-svn: 230006
entity, put the originally-canonical decl IDs in the right places in the redecl
chain rather than reordering them all to the start. If we don't ensure that the
redecl chain order is consistent with the topological module order, we can fail
to make a declaration visible if later declarations are in more IDNSs than
earlier ones (for instance, because the earlier decls are invisible friends).
llvm-svn: 228978
already have, check whether the name from the module is actually newer than the
existing declaration. If it isn't, we might (say) replace a visible declaration
with an injected friend, and thus make it invisible (or lose a default argument
or an array bound).
llvm-svn: 228661
context as anonymous for merging purposes. They can't be found by their names,
so we merge them based on their position within the surrounding context.
llvm-svn: 228485
of that entity, ensure that the redeclaration chain is reordered properly on
reload. Otherwise, the result of name lookup for that entity may point to an
entity that is too old; if that's an injected friend name or the like, that
can result in the name not being found at all.
llvm-svn: 228371
object. In such a case, use the TU's DC for merging global decls rather than
giving up when we find there is no TU scope.
Ultimately, we should probably avoid all loading of decls when preprocessing,
but there are other reasonable use cases for loading an AST file with no Sema
object for which this is the right thing.
llvm-svn: 228234
encountered any definition for the class; this happens when the definition is
added by an update record that is not yet loaded. In such a case, eagerly pick
the original parent of the member as the canonical definition of the class
rather than muddling through with the canonical declaration (the latter can
lead to us failing to merge properly later if the canonical definition turns
out to be some other declaration).
llvm-svn: 226977
* Put all input files under Inputs/, move corresponding tests into test/Modules.
* Rename a modulemap test file to [...].modulemap, and teach lit that such files are tests.
llvm-svn: 226875
record, and that class declaration is not the canonical definition of the
class, be sure to add the class to the list of classes that are consulted when
we look up a special member in the canonical definition.
llvm-svn: 226778
on top of a local declaration of the same entity, we still need to remember
that we loaded the first one or we may fail to merge the second one properly.
llvm-svn: 226765
load the definition data from the declaration itself. In that case, merge
properly; don't assume the prior definition is the same as our own.
llvm-svn: 226761
Importing _Builtin_intrinsics.sse and avx would transitively pull in those
headers, and the test would fail when building in an environment where
they were not available on the include path.
This fixes PR20995 for me.
Differential Revision: http://reviews.llvm.org/D7112
llvm-svn: 226754
If a module map contains
framework module * [extern_c] {}
We will now infer [extern_c] on the inferred framework modules (we
already inferred [system] as a special case).
llvm-svn: 225803
This just tweaks the fix from r224892 (which handled PCHs) to work with
modules, where we will serialize each method individually and hence the
hasMoreThanOneDecl bit needs to be updated as we add the methods.
llvm-svn: 225659
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223913
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
module, use the path from the module map file in preference to the path from
the .pcm file when resolving relative paths in the .pcm file. This allows
diagnostics (and .d output) to give relative paths if the module was found via
a relative path.
llvm-svn: 223577
This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.
llvm-svn: 220460
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
declaration in the instantiation if the previous declaration came from another
definition of the class template that got merged into the pattern definition.
llvm-svn: 219552
When building with modules enabled, we were defining max_align_t as a typedef
for a different anonymous struct type each time it was included, resulting in
an error if <stddef.h> is not covered by a module map and is included more than
once in the same modules-enabled compilation of C11 or C++11 code.
llvm-svn: 218931
I couldn't get something /really/ obvious, and I imagine Richard Smith
might be able to provide some text explaining the sequence of steps
that's demonstrated by these files - but at least it's a bit simpler
now.
llvm-svn: 218840
1. We were hitting the NextIsPrevious assertion because we were trying
to merge decl chains that were independent of each other because we had
no Sema object to allow them to find existing decls. This is fixed by
delaying loading the "preloaded" decls until Sema is available.
2. We were trying to get identifier info from an annotation token, which
asserts. The fix is to special-case the module annotations in the
preprocessed output printer.
Fixed in a single commit because when you hit 1 you almost invariably
hit 2 as well.
llvm-svn: 217550
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
It seems (I guess) in ObjC that va_list is provided without the need for
inclusions. I verified that with this change the test still crashes in
the absence of the fix committed in r217275.
llvm-svn: 217290
This innocuous statement to get the identifier info for __va_list_tag
was causing an assertion failure:
NextIsPrevious() && "decl became non-canonical unexpectedly"
if the __va_list_tag identifier was found in a PCH in some
circumstances, because it was looked up before the ASTReader had a Sema
object to use to find existing decls to merge with.
We could possibly move getting the identifier info even later, or make
it lazy if we wanted to, but this seemed like the minimal change.
Now why a PCH would have this identifier in the first place is a bit
mysterious. This seems to be related to the global module index in some
way, because when the test case is built without the global module index
it will not emit an identifier for __va_list_tag into the PCH, but with
the global module index it does.
llvm-svn: 217275
determining whether a declaration is out of line, instead of assuming
that the semantic and lexical DeclContext will be the same declaration
whenever they're the same entity.
This fixes behavior of declarations within merged classes and enums.
llvm-svn: 217008
pattern of an alias template declaration. Use this to merge alias templates
properly when they're members of class template specializations.
llvm-svn: 216437
declarations. We can't expect to find them in the canonical definition
of the class, because that's not where they live.
This means we no longer reject real ODR violations with friend declarations,
but we weren't consistently doing so anyway.
llvm-svn: 216369
declared, rather than putting them into the template parameter scope. We
previously had *no record* in the scope for class template declarations, once
those declarations completed and their template parameter scopes were popped.
This in turn caused us to be unable to merge class template declarations that
were declared in the global scope (where we use scope lookup rather than
DeclContext lookup for merging), when loading a module.
llvm-svn: 216311
members from all redefinitions of a class that have them, in case the special
member is defined in one module but only declared in another.
llvm-svn: 215675
definitions (because some other declaration declares a special member that
isn't present in the canonical definition), we need to search *all* of them; we
can't just stop when we find the requested name in any of the definitions,
because that can fail to find things (and in particular, it can fail to find
the member of the canonical declaration and return a bogus ODR failure).
llvm-svn: 215612
recursively within the emission of another inline function. This ultimately
led to us emitting the same inline function definition twice, which we then
rejected because we believed we had a mangled name conflict.
llvm-svn: 215579
With modules we start accessing headers for the first time while reading
the module map, which often has very different paths from the include
scanning logic.
Using the name by which the file was accessed gets us one step closer to
the right solution, which is using a FileName abstraction that decouples
the name by which a file was accessed from the FileEntry.
llvm-svn: 215541
redefinitions of that namespace have already been loaded. When writing out the
names in a namespace, if we see a name that is locally declared and had
imported declarations merged on top of it, export the local declaration as the
lookup result, because it will be the most recent declaration of that entity in
the redeclaration chain of an importer of the module.
llvm-svn: 215518
We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it if it
is an inferred framework module). Now we also verify any other module
map files that define submodules, such as when there is a
module.private.modulemap file.
llvm-svn: 215455
one, perform the import if the types match even if the imported declaration is
hidden. Otherwise, NamedDecl::declarationReplaces will drop one of the name
lookup entries, making the typedef effectively inaccessible from one of the
modules that declared it.
llvm-svn: 215306
also emit the updated 'operator delete' looked up for that destructor. Switch
from UpdateDecl to an actual update record when this happens due to implicitly
defining a special member function and unify this code path and the one for
instantiating a function definition.
llvm-svn: 215132
of a function has a resolved exception specification, then all declarations of
the function do.
We should probably improve the AST representation to make this implicit (perhaps
only store the exception specification on the canonical declaration), but this
fixes things for now.
The testcase for this (which used to assert) also exposes the actual bug I was
trying to reduce here: we sometimes fail to emit the body of an imported
special member function definition. Fix for that to follow.
llvm-svn: 214458
thorough tests.
Original commit message:
[modules] Fix macro hiding bug exposed if:
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213416
This is breaking the system modules on Darwin, because something that
was defined and re-exported no longer is. Might be this patch, or might
just be a really poor interaction with an existing visibility bug.
This reverts commit r213348.
llvm-svn: 213395
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
llvm-svn: 213348
into their container; we won't find them there. These things are already being
merged when they're added to their primary template's folding set, so this
merging is redundant (and causes us to reject-valid because we think we've
found an odr violation).
llvm-svn: 212788
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
gets explicitly specialized, don't reuse the previous class template
specialization declaration as a new declaration. The benefit here is fairly
marginal, it harms source fidelity, and this is horrible to model if the
specialization was imported from another module (without this change, it
asserts or worse).
llvm-svn: 209552
instantiated in another module, and the instantiation uses a partial
specialization, include the partial specialization and its template arguments
in the update record. We'll need them if someone imports the second module and
tries to instantiate a member of the template.
llvm-svn: 209472
declaration of that entity in from one of those modules, keep track of the fact
that we've not completed the redeclaration chain yet so that we can pull the
remaining declarations in from the other module if they're needed.
llvm-svn: 209161
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
llvm-svn: 208150
Warn on non-modular includes in various contexts.
-Wnon-modular-include
-Wnon-modular-include-in-module
-Wnon-modular-include-in-framework-module
Where each group is a subgroup of those above it.
llvm-svn: 208004
This fixes a bug where an update record causes us to load an entity that refers
to an entity we've not finished loading yet, resulting in badness.
llvm-svn: 207603
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
llvm-svn: 207152
together. This is extremely hairy, because in general we need to have loaded
both the template and the pattern before we can determine whether either should
be merged, so we temporarily violate the rule that all merging happens before
reading a decl ends, but *only* in the case where a template's pattern is being
loaded while loading the template itself.
In order to accomodate this for class templates, delay loading the injected
class name type for the pattern of the template until after we've loaded the
template itself, if we happen to load the template first.
llvm-svn: 207063
If a module doesn't meet a requirement, neither do its submodules. If we
don't propogate that, we might think it's an error to be missing a
header in one of those submodules.
llvm-svn: 206673
Unless they are in submodules that aren't available anyway, due to
requirements not being met. Also, mark children as unavailable when the
parent is.
llvm-svn: 206664
To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
cache-path/<module hash>/Foo.pcm
to
cache-path/<module hash>/Foo-<hash of module map path>.pcm
In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary. For example, if module A
imports module B
first time:
clang -I /path/to/A -I /path/to/B ...
second time:
clang -I /path/to/A -I /different/path/to/B ...
will now rebuild A as expected.
* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.
llvm-svn: 206201
an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.
llvm-svn: 204694
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
at which that PCH imported each visible submodule of the module. Such locations
are needed when synthesizing macro directives resulting from the import.
llvm-svn: 204417
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
The spelling location of stringified strings is not a file location.
Optimally, we'll want to solve the problem (as the FIXME states) by
handing in the right FileEntry of the #include location.
llvm-svn: 204220
to absolute paths when building the includes file for the module. Without this,
the module build would fail, because the relative paths we were using are not
necessarily relative to a directory in our include path.
llvm-svn: 203528
if the type's declaration was previously instantiated in an unimported module.
(For an imported type definition, this already worked, because the source
location is set to the location of the definition, but for locally-instantiated
type definitions, it did not.)
llvm-svn: 203425
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
llvm-svn: 203063
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
llvm-svn: 202560
Add the ImportDecl to the set of interesting delcarations that are
deserialized eagerly when an AST file is loaded (rather than lazily like
most decls). This is required to get auto linking to work when there is
no explicit import in the main file. Also resolve a FIXME to rename
'ExternalDefinitions', since that is only one of the things that need eager
deserialization. The new name is 'EagerlyDeserializedDecls'. The corresponding
AST bitcode is also renamed.
llvm-svn: 200505
Daniel Jasper