| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
includes search paths and diagnostics.
This is a recommit of r375322 and r375327 with a fix for the Windows test breakage.
llvm-svn: 375466
|
| |
|
|
|
|
|
|
| |
which includes search paths and diagnostics." and "[Docs] Fix header level."
The test doesn't work on Windows. I'll fix it and recommit later.
llvm-svn: 375338
|
| |
|
|
| |
llvm-svn: 375327
|
| |
|
|
|
|
|
|
| |
includes search paths and diagnostics.
Differential Revision: https://reviews.llvm.org/D68528
llvm-svn: 375322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allows module map writers to add build requirements based on
platform/os. This helps when target features and language dialects
aren't enough to conditionalize building a module, among other things,
it allow module maps for different platforms to live in the same file.
rdar://problem/43909745
Differential Revision: https://reviews.llvm.org/D51910
llvm-svn: 342499
|
| |
|
|
|
|
|
|
|
| |
Features added: c99, c11, c17, cplusplus14 and cplusplus17.
rdar://problem/36328787
rdar://problem/36668431
llvm-svn: 325154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to advertise private modules to be declared as submodules
(Foo.Private). This has proven to not scale well since private headers
might carry several dependencies, introducing unwanted content into the
main module and often causing dep cycles.
Change the canonical way to name it to Foo_Private, forcing private
modules as top level ones, and provide warnings under -Wprivate-module
to suggest fixes for other private naming. Update documentation to
reflect that.
rdar://problem/31173501
llvm-svn: 321337
|
| |
|
|
| |
llvm-svn: 313320
|
| |
|
|
| |
llvm-svn: 313318
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols
will eventually be exported through the named "public" module. This is
in support of a common pattern in the Darwin ecosystem where a single
public framework is constructed of several private frameworks, with
(currently) header duplication and some support from the linker.
Addresses rdar://problem/34438420.
llvm-svn: 313316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
llvm-svn: 312220
|
| |
|
|
|
|
|
|
| |
mapping
Looks like it breaks win10 builder.
llvm-svn: 312112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
llvm-svn: 312105
|
| |
|
|
| |
llvm-svn: 309976
|
| |
|
|
|
|
| |
Patch by ~paul (cynecx on phabricator)! Some test massaging by me.
llvm-svn: 309975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about that header file.
This has two purposes:
- It removes the need to eagerly `stat` every file referenced by a module map.
Instead, we track a list of unresolved header files with each size / mtime
(actually, for simplicity, we track submodules with such headers), and when
attempting to look up a header file based on a `FileEntry`, we check if there
are any unresolved header directives with that `FileEntry`'s size / mtime and
perform deferred `stat`s if so.
- It permits a preprocessed module to be compiled without the original files
being present on disk. The only reason we used to need those files was to get
the `stat` information in order to do header -> module lookups when using the
module. If we're provided with the `stat` information in the preprocessed
module, we can avoid requiring the files to exist.
Unlike most `header` directives, if a `header` directive with `stat`
information has no corresponding on-disk file the enclosing module is *not*
marked unavailable (so that behavior is consistent regardless of whether we've
resolved a header directive, and so that preprocessed modules don't get marked
unavailable). We could actually do this for all `header` directives: the only
reason we mark the module unavailable if headers are missing is to give a
diagnostic slightly earlier (rather than waiting until we actually try to build
the module / load and validate its .pcm file).
Differential Revision: https://reviews.llvm.org/D33703
llvm-svn: 304515
|
| |
|
|
|
|
| |
requires-declaration.
llvm-svn: 304253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33538
llvm-svn: 304107
|
| |
|
|
|
|
| |
This reverts commit r304054.
llvm-svn: 304057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used to detect if coroutines support is enabled in Clang.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33538
llvm-svn: 304054
|
| |
|
|
|
|
|
|
|
| |
Expand a bit on private modules with some guidance on how to write
them in the context of frameworks.
rdar://problem/24758771
llvm-svn: 298012
|
| |
|
|
|
|
|
|
|
| |
-fbuiltin-module-map loads the clang builtins modulemap file. (This is
equivalent to -fmodule-map-file=<resource dir>/include/module.modulemap)
Differential Revision: https://reviews.llvm.org/D25767
llvm-svn: 285548
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are
accepted.
The main motivation behind this is to prevent dep cycles between system
libraries (such as darwin) and libc++.
Patch by Richard Smith!
llvm-svn: 284797
|
| |
|
|
|
|
|
|
|
| |
This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.
Differential Revision: https://reviews.llvm.org/D23871
llvm-svn: 280613
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for modules that require (no-)gnu-inline-asm
environment, such as the compiler builtin cpuid submodule.
This is the gnu-inline-asm variant of https://reviews.llvm.org/D23871
Differential Revision: https://reviews.llvm.org/D23905
rdar://problem/26931199
llvm-svn: 280159
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In this mode, there is no need to load any module map and the programmer can
simply use "@import" syntax to load the module directly from a prebuilt
module path. When loading from prebuilt module path, we don't support
rebuilding of the module files and we ignore compatible configuration
mismatches.
rdar://27290316
Differential Revision: http://reviews.llvm.org/D23125
llvm-svn: 279096
|
| |
|
|
| |
llvm-svn: 247895
|
| |
|
|
| |
llvm-svn: 240110
|
| |
|
|
|
|
| |
-fno-module-maps). The old names are preserved for compatibility.
llvm-svn: 239792
|
| |
|
|
|
|
|
| |
These driver options never did anything (they weren't forwarded to the
frontend). Also update the documentation to not mention them.
llvm-svn: 239787
|
| |
|
|
|
|
|
| |
modules, and allow sub-modules of a module with a use-declaration to make use
of the nominated modules.
llvm-svn: 233323
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This suppresses the implicit search for files called 'module.modulemap' and
similar.
llvm-svn: 222745
|
| |
|
|
| |
llvm-svn: 220589
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
#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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.
Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.
Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.
llvm-svn: 218717
|
| |
|
|
| |
llvm-svn: 218614
|
| |
|
|
| |
llvm-svn: 213838
|
| |
|
|
|
|
| |
symbols in non-imported modules.
llvm-svn: 206977
|
| |
|
|
| |
llvm-svn: 206661
|
| |
|
|
|
|
| |
Don't install a file using the legacy spelling.
llvm-svn: 206431
|
| |
|
|
| |
llvm-svn: 205035
|
| |
|
|
|
|
| |
Requested in <rdar://problem/16188740>.
llvm-svn: 205030
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
within an extern "C" block in C++ code.
llvm-svn: 202615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 202117
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|