| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
It tried to introduce cyclic dependencies. Serialization shouldn't depend on Frontend, since Frontend depends on Serialization.
llvm-svn: 207497
|
|
|
|
| |
llvm-svn: 207479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
|
|
|
|
|
|
|
|
| |
unavailable
If the module is unavailable because of a missing header, don't diagnose
a "module * {}" declaration for having a missing umbrella.
llvm-svn: 206776
|
|
|
|
|
|
| |
imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations.
llvm-svn: 206680
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 206493
|
|
|
|
|
|
| |
relative to the module.map file.
llvm-svn: 206342
|
|
|
|
|
|
| |
certain file systems, treat them as if they were the same file.
llvm-svn: 206221
|
|
|
|
| |
llvm-svn: 206217
|
|
|
|
| |
llvm-svn: 206203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Target ABI code might add signext to the return types.
llvm-svn: 206107
|
|
|
|
|
| |
Review: http://reviews.llvm.org/D3335
llvm-svn: 206027
|
|
|
|
| |
llvm-svn: 205773
|
|
|
|
|
|
| |
directory in module B, don't include it in module B!
llvm-svn: 205762
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
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
|
|
|
|
| |
llvm-svn: 204574
|
|
|
|
|
|
|
| |
namespace, we need to update both the visible names of that namespace and of
its enclosing namespace set.
llvm-svn: 204570
|
|
|
|
|
|
|
| |
the update set rather than the current DeclContext. Add test for the local
extern case too.
llvm-svn: 204568
|
|
|
|
|
|
|
| |
out a visible update record for that namespace even if it was never declared in
this module.
llvm-svn: 204554
|
|
|
|
| |
llvm-svn: 204550
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
appropriate place, so that we only ask the external source once.
llvm-svn: 204535
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were 'allowing' the following import
@import Sub;
where Sub is a subframework of Foo and we had a -F path inside
Foo.framework/Frameworks and no module map file for Sub. This would
later hit assertion failures in debug builds.
Now we should correctly diagnose this as a module not found error.
llvm-svn: 204368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Test doesn't actually require production of an object file and for
some targets (e.g. hexagon) an assembler is not always available when
lit tests are run.
llvm-svn: 204144
|
|
|
|
| |
llvm-svn: 204116
|
|
|
|
|
|
|
| |
template specialization (from different modules), dump them all, so that every
declaration is dumped somewhere.
llvm-svn: 204100
|
|
|
|
| |
llvm-svn: 203929
|
|
|
|
|
|
|
|
|
|
|
| |
building one.
This is because the PCH is tied to the module files, if one of the module files changes or gets removed
the build system should re-build the PCH file.
rdar://16321245
llvm-svn: 203885
|
|
|
|
|
|
|
|
| |
doesn't show up as dependency of a module file.
Follow-up for rdar://15459210
llvm-svn: 203882
|
|
|
|
|
|
|
|
| |
When enabled, always validate the system headers when loading a module.
The end result of this is that when these headers change, we will notice
and rebuild the module.
llvm-svn: 203630
|
|
|
|
| |
llvm-svn: 203550
|
|
|
|
|
|
|
| |
already been loaded, apply that update record to the Decl immediately, rather
than adding it to a pending list and never applying it.
llvm-svn: 203534
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
blocks when building in C mode, and serialize and deserialize the attribute.
llvm-svn: 203317
|
|
|
|
| |
llvm-svn: 203215
|
|
|
|
|
|
| |
Somehow lost these in a git operation.
llvm-svn: 203210
|