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
The most common workflow with module reproducers involves deleting the
module cache before running the script. This happens because leftovers
from the crash are present in the cache and could trigger unrelated and
confusing errors, misleading from the initial reproduction intent.
Change this to point to a clean path but leave the leftovers untouched.
rdar://problem/28655070
llvm-svn: 289176
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.
llvm-svn: 265162
The VFS YAML files contain empty directory entries to describe that it's
returning from a subdirectory before describing new files in the parent.
In the future, we should properly sort and write YAML files avoiding
such empty dirs and mitigate the extra recurson cost. However, since
this is used by previous existing YAMLs, make the traversal work in
their presence.
rdar://problem/24499339
llvm-svn: 264970
Richard Smith