make -frewrite-includes also rewrite conditions in #if/#elif

Those conditions may use __has_include, which needs to be rewritten.
The existing code has already tried to rewrite just __has_include,
b

make -frewrite-includes also rewrite conditions in #if/#elif

Those conditions may use __has_include, which needs to be rewritten.
The existing code has already tried to rewrite just __has_include,
but it didn't work with macro expansion, so e.g. Qt's
"#define QT_HAS_INCLUDE(x) __has_include(x)" didn't get handled
properly. Since the preprocessor run knows what each condition evaluates
to, just rewrite the entire condition. This of course requires that
the -frewrite-include pass has the same setup as the following
compilation, but that has always been the requirement.

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

llvm-svn: 372248

show more ...

When preprocessing with -frewrite-imports and -fmodule-file=, do not pass all
modules to preprocessing of nested .pcm files.

Making those module files available results in loading more .pcm files th

When preprocessing with -frewrite-imports and -fmodule-file=, do not pass all
modules to preprocessing of nested .pcm files.

Making those module files available results in loading more .pcm files than
necessary, and potentially in misbehavior if a module makes itself visible
during its own compilation (as parts of that module that have not yet been
processed would then become visible).

llvm-svn: 306320

show more ...

Retain header search and preprocessing options from AST file when emitting
preprocessed text for an AST file.

llvm-svn: 304756

Attempt to fix Windows buildbot failure due to mismatching directory separators in preprocessed output.

llvm-svn: 304727

Rather than rejecting attempts to run preprocessor-only actions on AST files,
replay the steps taken to create the AST file with the preprocessor-only action
installed to produce preprocessed output.

Rather than rejecting attempts to run preprocessor-only actions on AST files,
replay the steps taken to create the AST file with the preprocessor-only action
installed to produce preprocessed output.

This can be used to produce the preprocessed text for an existing .pch or .pcm
file.

llvm-svn: 304726

show more ...

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 ...

[modules] When compiling a preprocessed module map, look for headers relative
to the original module map.

Also use the path and name of the original module map when emitting that
information into th

[modules] When compiling a preprocessed module map, look for headers relative
to the original module map.

Also use the path and name of the original module map when emitting that
information into the .pcm file. The upshot of this is that the produced .pcm
file will track information for headers in their original locations (where the
module was preprocessed), not relative to whatever directory the preprocessed
module map was in when it was built.

llvm-svn: 304346

show more ...

[modules] Switch from inferring owning modules based on source location to
inferring based on the current module at the point of creation.

This should result in no functional change except when buil

[modules] Switch from inferring owning modules based on source location to
inferring based on the current module at the point of creation.

This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.

There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.

llvm-svn: 303322

show more ...

If we are building a module, and we read a second description of the same
module from a different module map, ignore it.

This happens during builds of preprocessed modules (where it is harmless).

l

If we are building a module, and we read a second description of the same
module from a different module map, ignore it.

This happens during builds of preprocessed modules (where it is harmless).

llvm-svn: 302463

show more ...

Add support for building modules from preprocessed source.

To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file

Add support for building modules from preprocessed source.

To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.

Ignoring line markers, a preprocessed module might look like this:

module A {
header "a.h"
}
#pragma clang module contents
#pragma clang module begin A
// ... a.h ...
#pragma clang module end

The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.

A couple of major parts do not work yet:

1) The files that are listed in the module map must exist on disk, in order to
build the on-disk header -> module lookup table in the PCM file. To fix
this, we need the preprocessed output to track the file size and other stat
information we might use to build the lookup table.

2) Declaration ownership semantics don't work properly yet, since mapping from
a source location to a module relies on mapping from FileIDs to modules,
which we can't do if module transitions can occur in the middle of a file.

llvm-svn: 302309

show more ...

Add #pragma clang module begin/end pragmas and generate them when preprocessing a module.

These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. T

Add #pragma clang module begin/end pragmas and generate them when preprocessing a module.

These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.

Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).

llvm-svn: 302098

show more ...

Add pragma to perform module import and use it in -E output.

Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us wi

Add pragma to perform module import and use it in -E output.

Many of our supported configurations support modules but do not have any
first-class syntax to perform a module import. This leaves us with a problem:
there is no way to represent the expansion of a #include that imports a module
in the -E output for such languages. (We don't want to just leave it as a
#include because that requires the consumer of the preprocessed source to have
the same file system layout and include paths as the creator.)

This patch adds a new pragma:

#pragma clang module import MODULE.NAME.HERE

that imports a module, and changes -E and -frewrite-includes to use it when
rewriting a #include that maps to a module import. We don't make any attempt
to use a native language syntax import if one exists, to get more consistent
output. (If in the future, @import and #include have different semantics in
some way, the pragma will track the #include semantics.)

llvm-svn: 301725

show more ...

Move functionality for handling module maps as inputs from the -emit-module
action to the general FrontendAction infrastructure.

This permits applying -E, -ast-dump, -fsyntax-only, and so on to a mo

Move functionality for handling module maps as inputs from the -emit-module
action to the general FrontendAction infrastructure.

This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map
compilation. (The -E form is not currently especially useful yet as there's no
good way to take the output and use it to actually build a module.)

In order to support this, -cc1 now accepts -x <lang>-module-map in all cases
where it accepts -x <lang> for a language we can parse (not ir/ast). And for
uniformity, we also accept -x <lang>-header for all such languages (we used
to reject for cuda and renderscript), and -x <lang>-cpp-output for all such
languages (we used to reject for c, cl, and renderscript).

(None of these new alternatives are accepted by the driver yet, so no
user-visible changes.)

llvm-svn: 301610

show more ...