| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 210780
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209949
|
|
|
|
| |
llvm-svn: 209389
|
|
|
|
|
|
|
| |
And refactor to have just one place in code that sets up the empty
pragma handlers.
llvm-svn: 207758
|
|
|
|
|
|
|
|
| |
driver only thing and doesn't affect any language/preprocessor/etc. semantics.
rdar://16714526
llvm-svn: 207570
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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: 206217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
directory in module B, don't include it in module B!
llvm-svn: 205762
|
|
|
|
|
|
| |
class.
llvm-svn: 203758
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 203389
|
|
|
|
|
|
| |
blocks when building in C mode, and serialize and deserialize the attribute.
llvm-svn: 203317
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
|
|
|
| |
the module build stack for the module being built, so we can correctly detect
recursive module builds.
llvm-svn: 203006
|
|
|
|
|
|
| |
within an extern "C" block in C++ code.
llvm-svn: 202615
|
|
|
|
| |
llvm-svn: 202053
|
|
|
|
| |
llvm-svn: 202040
|
|
|
|
|
|
|
|
| |
We don't stat the system headers to check for stalenes during regular
PCH loading for performance reasons. When explicitly saying
-verify-pch, we want to check all the dependencies - user or system.
llvm-svn: 200979
|
|
|
|
|
|
|
|
|
| |
This option will:
- load the given pch file
- verify it is not out of date by stat'ing dependencies, and
- return 0 on success and non-zero on error
llvm-svn: 200884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 196510
|
|
|
|
|
|
|
|
| |
handle them (pr9537)"
It broke clang tests on some hosts with +Asserts. Seems "STDC" clashes.
llvm-svn: 196376
|
|
|
|
|
|
|
| |
And refactor to have just one place in code that sets up the empty
pragma handlers.
llvm-svn: 196372
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 192131
|
|
|
|
|
|
| |
follow.
llvm-svn: 184678
|
|
|
|
|
|
|
|
|
| |
a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.
llvm-svn: 184560
|
|
|
|
|
|
|
| |
headers may be included from within the module, but not from outside
the module.
llvm-svn: 184471
|
|
|
|
|
|
|
|
|
|
|
| |
information about a particular module file.
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
|
|
|
|
|
|
|
|
|
|
|
| |
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
llvm-svn: 176975
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
instead of messing with virtual files.
llvm-svn: 168062
|
|
|
|
|
|
| |
This means the main file for modules will always be a virtual one.
llvm-svn: 165591
|
|
|
|
|
|
| |
that are associated with a (sub)module.
llvm-svn: 165279
|
|
|
|
| |
llvm-svn: 161040
|
|
|
|
| |
llvm-svn: 160784
|
|
|
|
| |
llvm-svn: 158554
|
|
|
|
|
|
| |
out of the tree and use the tooling infrastructure.
llvm-svn: 154668
|
|
|
|
|
|
|
|
| |
list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.
llvm-svn: 153522
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
| |
temporary files with createOutputFile()
- This would otherwise happen as a side effect of llvm::sys::fs::unique_file creating parent directories.
llvm-svn: 151960
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
target-specific module requirements.
llvm-svn: 149224
|