member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
The change from r209195 turned out to be important to avoid saving stale
modification time/expected size information in a module file when there
are 3 or more modules in a dependency chain and the bottom one is
rebuilt. So add a test for that.
rdar://problem/17038180
llvm-svn: 209682
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
FileManager::invalidateCache is not safe to call when there may be
existing references to the file. What module load failure needs is
to refresh so stale stat() info isn't stored.
This may be the last user of invalidateCache; I'll take a look and
remove it if possible in a future commit.
This caused a use-after-free error as well as a spurious error message
that a module was "found in both 'X.pcm' and 'X.pcm'" in some cases.
llvm-svn: 209138
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
On reflection, this is better despite the missing command-line handling
bits for remarks. Making this a remark makes it much clearer that
this is purely informational and avoids the negative connotations of a
'warning'.
llvm-svn: 208367
But keep -Wnon-modular-include-in-[framework-]module
This warning is too noisy and doesn't really indicate a problem for most
people. Even though it would only really affect people using
-Weverything, that seems bad so remove it.
llvm-svn: 208345
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
Ideally, importing Foo.a from Foo.b would "do the right thing", but
until it does, this patch makes it an error rather than allow it to
silently be ignored.
llvm-svn: 207948
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
Fixed by moving ProcessWarningOptions from Frontend into Basic. All of
the dependencies for ProcessWarningOptions were already in Basic, so
this was a small change.
llvm-svn: 207549
This patch checks whether the diagnostic options that could lead to
errors (principally -Werror) are consistent between when a module was
built and when it is loaded. If there are new -Werror flags, then the
module is rebuilt. In order to canonicalize the options we do this
check at the level of the constructed DiagnosticsEngine, which contains
the final set of diag to diagnostic level mappings. Currently we only
rebuild with the new diagnostic options, but we intend to refine this in
the future to include the union of the new and old flags, since we know
the old ones did not cause errors. System modules are only rebuilt when
-Wsystem-headers is enabled.
One oddity is that unlike checking language options, we don’t perform
this diagnostic option checking when loading from a precompiled header.
The reason for this is that the compiler cannot rebuild the PCH, so
anything that requires it to be rebuilt effectively leaks into the build
system. And in this case, that would mean the build system
understanding the complex relationship between diagnostic options and
the underlying diagnostic mappings, which is unreasonable. Skipping the
check is safe, because these options do not affect the generated AST.
You simply won’t get new build errors due to changed -Werror options
automatically, which is also true for non-module cases.
llvm-svn: 207477
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
Otherwise including a header in your source file that is not included by
framework's umbrella header will silently add an empty submodule with that
name.
is automatically translated to
@import Foo.NotInModule;
which then would have succeeded because the inferred module map
contained an empty submodule called NotInModule.
llvm-svn: 207024
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
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
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
Richard Smith