| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 191562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|