using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
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
Removes some old code that allowed a module to be loaded from a pcm file
even if the module.map could not be found. Also update a number of
tests that relied on the old behavior.
llvm-svn: 199852
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
If a header file belonging to a certain module is not found on the
filesystem, that header gets marked as unavailable. Now, the layering
warning (-fmodules-decluse) should still warn about headers of this
module being wrongfully included. Currently, headers belonging to those
modules are just treated as not belonging to modules at all which means
they can be included freely from everywhere.
To implement this (somewhat) cleanly, I have moved most of the layering
checks into the ModuleMap. This will also help with showing FixIts
later.
llvm-svn: 197805
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
This works towards the long-term goal of not stat'ing the header files at all
while reading the module map and instead read them only when the module is
being built (there is a corresponding FIXME in parseHeaderDecl()). However, it
seems non-trivial to get there and this unblock us and moves us into the right
direction.
Also changed the implementation to reuse the same DiagnosticsEngine.
llvm-svn: 197485
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
A better long-term strategy might be to not stat the header files at all
while reading the module map and instead read them only when the module
is being built (there is a corresponding FIXME in parseHeaderDecl()).
However, it seems non-trivial to get there and this would be a temporary
solution to unblock us.
Also changed the implementation to reuse the same DiagnosticsEngine as
otherwise warnings can't be enabled or disabled with command-line flags.
llvm-svn: 197388
Includes might always pull in arbitrary header or data files outside of
modules. Among others, this includes builtin includes, which do not have
a module (story) yet.
Also cleanup implementation of ModuleMap::findModuleForHeader() to be
non-recursive.
llvm-svn: 197034
Specifically, we want to warn only for direct layering violations for
the modules we are calling clang on.
This temporarily unblocks
http://llvm-reviews.chandlerc.com/D2374
Once that is in, we'll also want to investigate whether to check the
layering in the build step of modules that we build transitively.
llvm-svn: 197021
In order to make the migration to modules easier, it seems to be helpful
to allow a 1:1 mapping between target names of a current build system
and the corresponding C++ modules. As such targets commonly contain
characters like "-". ":" and "/", allowing arbitrary quote-escaped
strings seems to be a straightforward option.
After several offline discussions, the precise mechanisms for C++
module names especially regarding submodules and import statements has
yet to be determined. Thus, this patch only enables string literals as
names inside the module map files which can be used by automatic module
import (through #include).
Also improve the error message on missing use-declarations.
llvm-svn: 196573
Before, there SourceManager would not return a FileEntry for a
SourceLocation of a macro expansion (if the header name itself is
defined in a macro). We'd then fallback to assume that the module
currently being built is the including module. However, in this case we
are actually interested in the spelling location of the filename loc in
order to derive the including module.
llvm-svn: 196311
module. Use the marker to diagnose cases where we try to transition between
submodules when not at the top level (most likely because a closing brace was
missing at the end of a header file, but is also possible if submodule headers
attempt to do something fundamentally non-modular, like our .def files).
llvm-svn: 195543
representing the module import rather than making the module immediately
visible. This serves two goals:
* It avoids making declarations in the module visible prematurely, if we
walk past the #include during a tentative parse, for instance, and
* It gives a diagnostic (although, admittedly, not a very nice one) if
a header with a corresponding module is included anywhere other than
at the top level.
llvm-svn: 194782
The preprocessor currently recognizes module declarations to load a
module based on seeing the 'import' keyword followed by an
identifier. This sequence is fairly unlikely in C (one would need a
type named 'import'), but is more common in Objective-C (where a
variable named 'import' can cause problems). Since import declarations
currently require a leading '@', recognize that in the preprocessor as
well. Fixes <rdar://problem/15084587>.
llvm-svn: 194225
This change fixes Richard's testcase for r193815. Now we include non-explicit
submodules into the list of exports.
The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
correct module set -- it only considers modules that are imported.
The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.
llvm-svn: 194018
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
llvm-svn: 193314
modules.
With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).
llvm-svn: 193219
This patch changes two things:
a) Allow a header to be part of multiple modules. The reasoning is that
in existing codebases that have a module-like build system, the same
headers might be used in several build targets. Simple reasons might be
that they defined different classes that are declared in the same
header. Supporting a header as a part of multiple modules will make the
transistion easier for those cases. A later step in clang can then
determine whether the two modules are actually compatible and can be
merged and error out appropriately. The later check is similar to what
needs to be done for template specializations anyway.
b) Allow modules to be stored in a directory tree separate from the
headers they describe.
Review: http://llvm-reviews.chandlerc.com/D1951
llvm-svn: 193151
If we have multiple definitions of the same entity from different modules, we
nominate the first definition which we see as being the canonical definition.
If we load a declaration from a different definition and we can't find a
corresponding declaration in the canonical definition, issue a diagnostic.
This is insufficient to prevent things from going horribly wrong in all cases
-- we might be in the middle of emitting IR for a function when we trigger some
deserialization and discover that it refers to an incoherent piece of the AST,
by which point it's probably too late to bail out -- but we'll at least produce
a diagnostic.
llvm-svn: 192950
This change doesn't go all the way to making fields redeclarable; instead, it
makes them 'mergeable', which means we can find the canonical declaration, but
not much else (and for a declaration that's not from a module, the canonical
declaration is always that declaration).
llvm-svn: 192092
With this option, arbitrarily named module map files can be specified
to be loaded as required for headers in the respective (sub)directories.
This, together with the extern module declaration allows for specifying
module maps in a modular fashion without the need for files called
"module.map".
Among other things, this allows a directory to contain two modules that
are completely independent of one another.
Review: http://llvm-reviews.chandlerc.com/D1697.
llvm-svn: 191284
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
llvm-svn: 191283
This patch is the first step to make module-map-files modular (instead
of requiring a single "module.map"-file per include directory). This
step adds a new "extern module" declaration that enables
module-map-files to reference one another along with a very basic
implementation.
The next steps are:
* Combine this with the use-declaration (from
http://llvm-reviews.chandlerc.com/D1546) in order to only load module
map files required for a specific compilation.
* Add an additional flag to start with a specific module-map-file (instead
of requiring there to be at least one "module.map").
Review: http://llvm-reviews.chandlerc.com/D1637
llvm-svn: 190497
it is an implicit instantiation of a class template specialization), pick the
first-loaded definition to be the canonical definition, and merge all other
definitions into it.
This is still rather incomplete -- we need to extend every form of declaration
that can appear within a CXXRecordDecl to be redeclarable if it came from an
AST file (this includes fields, enumerators, ...).
llvm-svn: 190315
name lookup from lazily deserializing the other declarations with the same
name, by tracking a bit to indicate whether a name in a DeclContext might have
additional external results. This also allows lazier reconciling of the lookup
table if a module import adds decls to a pre-existing DC.
However, this exposes a pre-existing bug, which causes a regression in
test/Modules/decldef.mm: if we have a reference to a declaration, and a
later-imported module adds a redeclaration, nothing causes us to load that
redeclaration when we use or emit the reference (which can manifest as a
reference to an undefined inline function, a use of an incomplete type, and so
on). decldef.mm has been extended with an additional testcase which fails with
or without this change.
llvm-svn: 190293
When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit. We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.
This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.
Fixes PR16635.
llvm-svn: 190016
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.
Patch by Ron Ofir.
llvm-svn: 188174
in one module but is only declared as a friend in another module, keep it
visible in the result of the merge.
This is incomplete on two axes:
1) Our handling of local extern declarations is basically broken (we put them
in the wrong decl context, and don't find them in redeclaration lookup, unless
they've previously been declared), and this results in them making friends
visible after a merge.
2) Eventually we'll need to mark that this has happened, and more carefully
check whether a declaration should be visible if it was only visible in some
of the modules in which it was declared. Fortunately it's rare for the
identifier namespace of a declaration to change along its redeclaration chain.
llvm-svn: 187639
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.
The fix here has two parts:
1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.
2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.
There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.
llvm-svn: 187167
global allocation or deallocation function, that should not cause that global
allocation or deallocation function to become unavailable.
llvm-svn: 186270
numbers as we deserialize class template partial specializations. We can't
assume that the old sequence numbers will work.
The sequence numbers are still deterministic, but are now a lot less
predictable for class template partial specializations in modules/PCH.
llvm-svn: 184811
constructing a lookup table.
Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.
Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.
llvm-svn: 184696
As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.
I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.
llvm-svn: 184504
Clang has an issue between mingw/include/float.h and clang/Headers/float.h with cyclic include_next.
For now, it should work to suppress #include_next in clang/float.h with an explicit target.
(It may work with -U__MINGW32__, though.)
llvm-svn: 181988
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
llvm-svn: 181847
After r180934 we may initiate module map parsing for modules not related to the module what we are building,
make sure we ignore the header file info of headers from such modules.
First part of rdar://13840148
llvm-svn: 181489
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
llvm-svn: 181426
Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.
Fixes <rdar://problem/13663996>.
llvm-svn: 181067
The "magical" builtin headers are the headers we provide as part of
the C standard library, which typically comes from /usr/include. We
essentially merge our headers into that location (due to cyclic
dependencies). This change makes sure that, when header search finds
one of our builtin headers, we figure out which module it actually
lives in. This case is fairly rare; one ends up having to include one
of the few built-in C headers we provide before including anything
from /usr/include to trigger it. Fixes <rdar://problem/13787184>.
llvm-svn: 180934
-Make sure that a deserialized external decl gets added to the TU scope.
-When associating an identifier with a set of decls, use the most recent local ones,
if they exist, otherwise associating decls from modules (that came after a local one)
will lead to an incomplete reconstructed re-declaration chain.
rdar://13712705
llvm-svn: 180634
Microsoft's Source Annotation Language (SAL) defines a bunch of keywords
for annotating the inputs and outputs of functions. Empty definitions
for the keywords are provided by <stdlib.h> -> <crtdefs.h> -> <sal.h>.
This makes it basically impossible to include MSVC's stdlib.h and
Clang's *mmintrin.h headers at the same time if they have variables
named __in. As a workaround, I've renamed those variables.
This fixes the Modules/compiler_builtins.m test which was XFAILed,
presumably due to this conflict.
llvm-svn: 179860
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
llvm-svn: 179677
- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
llvm-svn: 179612
This is a Darwin-SDK-specific hash criteria used to identify a
particular SDK without having to hash the contents of all of its
headers. If other platforms have such versioned files, we should add
those checks here.
llvm-svn: 179346
Normal name lookup ignores any hidden declarations. When name lookup
for builtin declarations fails, we just synthesize a new
declaration at the point of use. With modules, this could lead to
multiple declarations of the same builtin, if one came from a (hidden)
submodule that was later made visible. Teach name lookup to always
find builtin names, so we don't create these redundant declarations in
the first place.
llvm-svn: 178711
Syntactically means the function macro parameter names do not need to use the same
identifiers in order for the definitions to be considered identical.
Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also
use this kind of comparison to check for ambiguous macros coming from modules.
rdar://13562254
llvm-svn: 178671
This option can be useful for end users who want to know why they
ended up with a ton of different variants of the "std" module in their
module cache. This problem should go away over time, as we reduce the
need for module variants, but it will never go away entirely.
llvm-svn: 178148
Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
undefining of macros in the translation unit that imported that submodule.
This reduces macro namespace interference across modules.
llvm-svn: 178105
Clang's <stddef.h> provides definitions for the C standard library
types size_t, ptrdiff_t, and wchar_t. However, the system's C standard
library headers tend to provide the same typedefs, and the two
generally avoid each other using the macros
_SIZE_T/_PTRDIFF_T/_WCHAR_T. With modules, however, we need to see
*all* of the places where these types are defined, so provide the
typedefs (ignoring the macros) when modules are enabled.
llvm-svn: 177686
We now put the Clang module cache in
<system-temp-directory>/org.llvm.clang/ModuleCache. Perhaps some day
there will be other caches under <system-temp-directory>/org.llvm.clang>.
llvm-svn: 177671
Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module variants
for different values of these macros. A module can declare its
configuration macros, in which case we will complain if the definition
of a configation macro on the command line (or lack thereof) differs
from the current preprocessor state at the point where the module is
imported. This should eliminate some surprises when enabling modules,
because "#define CONFIG_MACRO ..." followed by "#include
<module/header.h>" would silently ignore the CONFIG_MACRO setting. At
least it will no longer be silent about it.
Configuration macros are eventually intended to help reduce the number
of module variants that need to be built. When the list of
configuration macros for a module is exhaustive, we only need to
consider the settings for those macros when building/finding the
module, which can help isolate modules for various project-specific -D
flags that should never affect how modules are build (but currently do).
llvm-svn: 177466
The global module index was querying the file manager for each of the
module files it knows about at load time, to prune out any out-of-date
information. The file manager would then cache the results of the
stat() falls used to find that module file.
Later, the same translation unit could end up trying to import one of the
module files that had previously been ignored by the module cache, but
after some other Clang instance rebuilt the module file to bring it
up-to-date. The stale stat() results in the file manager would
trigger a second rebuild of the already-up-to-date module, causing
failures down the line.
The global module index now lazily resolves its module file references
to actual AST reader module files only after the module file has been
loaded, eliminating the stat-caching race. Moreover, the AST reader
can communicate to its caller that a module file is missing (rather
than simply being out-of-date), allowing us to simplify the
module-loading logic and allowing the compiler to recover if a
dependent module file ends up getting deleted.
llvm-svn: 177367
This commit introduces a set of related changes to ensure that the
declaration that shows up in the identifier chain after deserializing
declarations with a given identifier is, in fact, the most recent
declaration. The primary change involves waiting until after we
deserialize and wire up redeclaration chains before updating the
identifier chains. There is a minor optimization in here to avoid
recursively deserializing names as part of looking to see whether
top-level declarations for a given name exist.
A related change that became suddenly more urgent is to property
record a merged declaration when an entity first declared in the
current translation unit is later deserialized from a module (that had
not been loaded at the time of the original declaration). Since we key
off the canonical declaration (which is parsed, not from an AST file)
for emitted redeclarations, we simply record this as a merged
declaration during AST writing and let the readers merge them.
Re-fixes <rdar://problem/13189985>, presumably for good this time.
llvm-svn: 175447
the linkage of functions and variables while merging declarations from modules,
and we don't necessarily have enough of the rest of the AST loaded at that
point to allow us to compute linkage, so serialize it instead.
llvm-svn: 174943
lexical storage but not visible storage' case in C++. It's unclear whether we
even need the special-case handling for C++, since it seems to be working
around our not serializing a lookup table for the TU in C. But in any case,
the assertion is incorrect.
llvm-svn: 174931
These two related tweaks to keep the information associated with a
given identifier correct when the identifier has been given some
top-level information (say, a top-level declaration) and more
information is then loaded from a module. The first ensures that an
identifier that was "interesting" before being loaded from an AST is
considered to be different from its on-disk counterpart. Otherwise, we
lose such changes when writing the current translation unit as a
module.
Second, teach the code that injects AST-loaded names into the
identifier chain for name lookup to keep the most recent declaration,
so that we don't end up confusing our declaration chains by having a
different declaration in there.
llvm-svn: 174895
visible.
The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,
class X;
X *x;
and then import a module that includes a definition of X:
import XDef;
We will then fail when attempting to access a member of X, e.g.,
x->method()
because the AST reader did not know to look for a default of a class
named X within the new module.
This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.
In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,
// module 1
namespace N { struct X; }
// module 2
namespace N { struct X { /* ... */ }; }
One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.
llvm-svn: 174794
included in the same test. Clang gets confused about whether it's already built
a module for this file, when running on a content-addressible filesystem.
llvm-svn: 174694
overloads of a name by claiming that there are no lookup results for that name
in modules while loading the names from the module. Lookups in deserialization
really don't want to find names which they themselves are in the process of
introducing. This also has the pleasant side-effect of automatically caching
PCH lookups which found no names.
The runtime here is still quadratic in the number of overloads, but the
constant is lower.
llvm-svn: 174685
name lookup has been performed in that context (this probably only happens in
C++).
1) Whenever we add names to a context, set a flag on it, and if we perform
lookup and discover that the context has had a lookup table built but has the
flag set, update all entries in the lookup table with additional names from
the external source.
2) When marking a DeclContext as having external visible decls, mark the
context in which lookup is performed, not the one we are adding. These won't
be the same if we're adding another copy of a pre-existing namespace.
llvm-svn: 174577
The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
llvm-svn: 174560
This can happen when one abuses precompiled headers by passing more -D
options when using a precompiled hedaer than when it was built. This
is intentionally permitted by precompiled headers (and is exploited by
some build environments), but causes problems for modules.
First part of <rdar://problem/13165109>, detecting when something when
horribly wrong.
llvm-svn: 174554
Different modules may have different views of the various "special"
types in the AST, such as the redefinition type for "id". Merge those
types rather than only considering the redefinition types for the
first AST file loaded.
llvm-svn: 174234
-fno-modules-global-index -cc1 option to allow one to disable the
index for performance testing purposes, but with a 10% win in
-fsyntax-only time, there is no reason a user would do this.
llvm-svn: 173707
AST reader.
The global module index tracks all of the identifiers known to a set
of module files. Lookup of those identifiers looks first in the global
module index, which returns the set of module files in which that
identifier can be found. The AST reader only needs to look into those
module files and any module files not known to the global index (e.g.,
because they were (re)built after the global index), reducing the
number of on-disk hash tables to visit. For an example source I'm
looking at, we go from 237844 total identifier lookups into on-disk
hash tables down to 126817.
Unfortunately, this does not translate into a performance advantage.
At best, it's a wash once the global module index has been built, but
that's ignore the cost of building the global module index (which
is itself fairly large). Profiles show that the global module index
code is far less efficient than it should be; optimizing it might give
enough of an advantage to justify its continued inclusion.
llvm-svn: 173405
The global module index is a "global" index for all of the module
files within a particular subdirectory in the module cache, which
keeps track of all of the "interesting" identifiers and selectors
known in each of the module files. One can perform a fast lookup in
the index to determine which module files will have more information
about entities with a particular name/selector. This information can
help eliminate redundant lookups into module files (a serious
performance problem) and help with creating auto-import/auto-include
Fix-Its.
The global module index is created or updated at the end of a
translation unit that has triggered a (re)build of a module by
scraping all of the .pcm files out of the module cache subdirectory,
so it catches everything. As with module rebuilds, we use the file
system's atomicity to synchronize.
llvm-svn: 173301
that redefined a macro without undef'ing it first.
Proper reconstruction of the macro info history from modules will properly fix this in subsequent commits.
rdar://13016031
llvm-svn: 173281
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
!0 = metadata !{metadata !"-lautolink"}
!1 = metadata !{metadata !"-framework", metadata !"autolink_framework"}
referenced from llvm.module.linkoptions, e.g.,
!llvm.module.linkoptions = !{!0, !1, !2, !3}
This conceptually moves the logic for figuring out the syntax the
linker will accept from LLVM into Clang. Moreover, it makes it easier
to support MSVC's
#pragma comment(linker, "some option")
in the future, should anyone care to do so.
llvm-svn: 172441
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
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.
Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.
llvm-svn: 172290
(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
RUN: a
RUN: b || true
lit expands it to a && b || true, and the || true applies to both commands (thus ignoring failures in 'a')! This is PR10867 again.
llvm-svn: 169434
state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>
llvm-svn: 169057
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
llvm-svn: 169042
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
llvm-svn: 169021
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
llvm-svn: 168961
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
While we're here, extend the module map to cover most of the
newly-added instrinsic headers. Only wmmintrin.h is missing, because
it needs to be split into AES/PCLMUL subheaders (as a separate commit).
llvm-svn: 167398
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
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
llvm-svn: 162464
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
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
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
On Cygwin, at first, <stddef.h> is included without __need_wint_t.
Next, <stddef.h> is included with __need_wint_t, though Modules feature would not process <stddef.h> twice.
Then, wint_t is not found in system headers.
llvm-svn: 149500
builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.
llvm-svn: 149434
each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.
Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.
llvm-svn: 149227
headers. The remaining headers require more sophisticated
requirements; they'll be handled separately. Part of
<rdar://problem/10710060>.
llvm-svn: 149206
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
Richard Smith