-frewrite-imports: Add support for wildcard rules in umbrella modules with

This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at t

-frewrite-imports: Add support for wildcard rules in umbrella modules with

This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at the issues with -verify and filesystem checks (the fact that the behavior depends on the existence of a 'foo' directory even though it shouldn't need it), etc.

Reviewers: rsmith

Differential Revision: https://reviews.llvm.org/D61656

llvm-svn: 360195

show more ...

Enable coroutines under -std=c++2a.

llvm-svn: 354736

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separat

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637

show more ...

[Modules] Add platform and environment features to requires clause

Allows module map writers to add build requirements based on
platform/os. This helps when target features and language dialects
are

[Modules] Add platform and environment features to requires clause

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

show more ...

When we leave a module header, make that header visible in its
includer's context, even if its overall module is unavailable.

llvm-svn: 342096

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. Thi

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46320

llvm-svn: 331834

show more ...

Record whether a module came from a private module map

Right now we only use this information in one place, immediately after
we calculate it, but it's still nice information to have. The Swift
proj

Record whether a module came from a private module map

Right now we only use this information in one place, immediately after
we calculate it, but it's still nice information to have. The Swift
project is going to use this to tidy up its "API notes" feature (see
past discussion on cfe-dev that never quite converged).

Reviewed by Bruno Cardoso Lopes.

llvm-svn: 330452

show more ...

[Modules] Add more language features to be used with requires-declaration

Features added: c99, c11, c17, cplusplus14 and cplusplus17.

rdar://problem/36328787
rdar://problem/36668431

llvm-svn: 3251

[Modules] Add more language features to be used with requires-declaration

Features added: c99, c11, c17, cplusplus14 and cplusplus17.

rdar://problem/36328787
rdar://problem/36668431

llvm-svn: 325154

show more ...

Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments,

Reapply r321781: [Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.

This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.

Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html

Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html

Differential Revision: https://reviews.llvm.org/D31269

rdar://problem/23612102

llvm-svn: 321855

show more ...

Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones"

This reverts r321781 until I fix the leaks pointed out by bots:

http://lab.llvm.org:8011/builders/san

Revert "[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones"

This reverts r321781 until I fix the leaks pointed out by bots:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12146
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/3741

llvm-svn: 321786

show more ...

[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to ov

[Modules] Allow modules specified by -fmodule-map-file to shadow implicitly found ones

When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.

This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.

Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html

Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html

Differential Revision: https://reviews.llvm.org/D31269

rdar://problem/23612102

llvm-svn: 321781

show more ...

[Basic] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 317381

[Module map] Introduce a private module re-export directive.

Introduce a new "export_as" directive for top-level modules, which
indicates that the current module is a "private" module whose symbols

[Module map] Introduce a private module re-export directive.

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

show more ...

Support non-identifier module names when preprocessing modules.

llvm-svn: 305758

Support lazy stat'ing of files referenced by module maps.

This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about t

Support lazy stat'ing of files referenced by module maps.

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

show more ...

[coroutines] Support "coroutines" feature in module map requires clause

Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used t

[coroutines] Support "coroutines" feature in module map requires clause

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

show more ...

Revert "[coroutines] Support "coroutines" feature in module map requires clause"

This reverts commit r304054.

llvm-svn: 304057

[coroutines] Support "coroutines" feature in module map requires clause

Summary: In order for libc++ to add `<experimental/coroutine>` to its module map, there has to be a feature that can be used t

[coroutines] Support "coroutines" feature in module map requires clause

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

show more ...

Modular Codegen: Add/use a bit in serialized function definitions to track whether they are the subject of modular codegen

Some decls are created not where they are written, but in other module
file

Modular Codegen: Add/use a bit in serialized function definitions to track whether they are the subject of modular codegen

Some decls are created not where they are written, but in other module
files/users (implicit special members and function template implicit
specializations). To correctly identify them, use a bit next to the definition
to track the modular codegen property.

Discussed whether the module file bit could be omitted in favor of
reconstituting from the modular codegen decls list - best guess today is that
the efficiency improvement of not having to deserialize the whole list whenever
any function is queried by a module user is worth it for the small size
increase of this redundant (list + bit-on-def) representation.

Reviewers: rsmith

Differential Revision: https://reviews.llvm.org/D29901

llvm-svn: 299982

show more ...

Modules: Use hash of PCM content for SIGNATURE

Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.

- Move definition ASTFileSignature to Basic/Module.h so Module a

Modules: Use hash of PCM content for SIGNATURE

Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.

- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.

- Change the signature from uint64_t to std::array<uint32_t,5>.

- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.

- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.

This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).

Design and original patch by Manman Ren!

llvm-svn: 297655

show more ...

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where thos

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).

External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).

Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.

Reviewers: rsmith

Differential Revision: https://reviews.llvm.org/D28845

llvm-svn: 293456

show more ...

[Modules] Add 'no_undeclared_includes' module map attribute

The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are

[Modules] Add 'no_undeclared_includes' module map attribute

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

show more ...

[Modules] Add 'freestanding' to the 'requires-declaration' feature-list.

This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.

[Modules] Add 'freestanding' to the 'requires-declaration' feature-list.

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

show more ...