maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/preprocess-module.cpp

160 lines
7.8 KiB
C++
Raw Normal View History

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
2017-04-28 09:49:42 +08:00
// RUN: rm -rf %t
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
2017-05-06 06:18:51 +08:00
// RUN: mkdir %t
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
2017-04-28 09:49:42 +08:00
// RUN: not %clang_cc1 -fmodules -fmodule-name=file -I%S/Inputs/preprocess -x c++-module-map %S/Inputs/preprocess/module.modulemap -E 2>&1 | FileCheck %s --check-prefix=MISSING-FWD
// MISSING-FWD: module 'fwd' is needed
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
2017-05-06 06:18:51 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-name=fwd -I%S/Inputs/preprocess -x c++-module-map %S/Inputs/preprocess/module.modulemap -emit-module -o %t/fwd.pcm
// Check that we can preprocess modules, and get the expected output.
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%S/Inputs/preprocess -x c++-module-map %S/Inputs/preprocess/module.modulemap -E -o %t/no-rewrite.ii
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%S/Inputs/preprocess -x c++-module-map %S/Inputs/preprocess/module.modulemap -E -frewrite-includes -o %t/rewrite.ii
//
// RUN: FileCheck %s --input-file %t/no-rewrite.ii --check-prefix=CHECK --check-prefix=NO-REWRITE
// RUN: FileCheck %s --input-file %t/rewrite.ii --check-prefix=CHECK --check-prefix=REWRITE
// Check that we can build a module from the preprocessed output.
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -x c++-module-map-cpp-output %t/no-rewrite.ii -emit-module -o %t/no-rewrite.pcm
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -x c++-module-map-cpp-output %t/rewrite.ii -emit-module -o %t/rewrite.pcm
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
2017-05-09 04:30:47 +08:00
// Check that we can load the original module map in the same compilation (this
// could happen if we had a redundant -fmodule-map-file= in the original
// build).
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -fmodule-map-file=%S/Inputs/preprocess/module.modulemap -x c++-module-map-cpp-output %t/rewrite.ii -emit-module -o /dev/null
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
2017-05-06 06:18:51 +08:00
// Check the module we built works.
[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
2017-05-18 10:29:20 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/no-rewrite.pcm %s -I%t -verify -fno-modules-error-recovery
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/rewrite.pcm %s -I%t -verify -fno-modules-error-recovery -DREWRITE
[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
2017-06-01 04:56:55 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/no-rewrite.pcm %s -I%t -verify -fno-modules-error-recovery -DINCLUDE -I%S/Inputs/preprocess
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/rewrite.pcm %s -I%t -verify -fno-modules-error-recovery -DREWRITE -DINCLUDE -I%S/Inputs/preprocess
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
2017-05-06 06:18:51 +08:00
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
2017-06-02 09:55:39 +08:00
// Now try building the module when the header files are missing.
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
2017-06-27 03:39:25 +08:00
// RUN: cp %S/Inputs/preprocess/fwd.h %S/Inputs/preprocess/file.h %S/Inputs/preprocess/file2.h %S/Inputs/preprocess/other.h %S/Inputs/preprocess/module.modulemap %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
2017-06-02 09:55:39 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%t -x c++-module-map %t/module.modulemap -E -frewrite-includes -o %t/copy.ii
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
2017-06-27 03:39:25 +08:00
// RUN: rm %t/fwd.h %t/file.h %t/file2.h %t/other.h %t/module.modulemap
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
2017-06-02 09:55:39 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -x c++-module-map-cpp-output %t/copy.ii -emit-module -o %t/copy.pcm
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
2017-06-06 02:10:11 +08:00
// Check that our module contains correct mapping information for the headers.
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
2017-06-27 03:39:25 +08:00
// RUN: cp %S/Inputs/preprocess/fwd.h %S/Inputs/preprocess/file.h %S/Inputs/preprocess/file2.h %S/Inputs/preprocess/other.h %S/Inputs/preprocess/module.modulemap %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
2017-06-02 09:55:39 +08:00
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/copy.pcm %s -I%t -verify -fno-modules-error-recovery -DCOPY -DINCLUDE
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
2017-06-27 03:39:25 +08:00
// RUN: rm %t/fwd.h %t/file.h %t/file2.h %t/other.h %t/module.modulemap
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
2017-05-06 06:18:51 +08:00
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
2017-06-06 02:10:11 +08:00
// Check that we can preprocess from a .pcm file and that we get the same result as preprocessing from the original sources.
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%S/Inputs/preprocess -x c++-module-map %S/Inputs/preprocess/module.modulemap -emit-module -o %t/file.pcm
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%S/Inputs/preprocess %t/file.pcm -E -frewrite-includes -o %t/file.rewrite.ii
Attempt to fix Windows buildbot failure due to mismatching directory separators in preprocessed output. llvm-svn: 304727
2017-06-06 02:39:31 +08:00
// FIXME: This check fails on Windows targets, due to canonicalization of directory separators.
// FIXME: cmp %t/rewrite.ii %t/file.rewrite.ii
// FIXME: Instead, just check that the preprocessed output is functionally equivalent to the output when preprocessing from the original sources.
// RUN: FileCheck %s --input-file %t/file.rewrite.ii --check-prefix=CHECK --check-prefix=REWRITE
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -x c++-module-map-cpp-output %t/file.rewrite.ii -emit-module -o %t/file.rewrite.pcm
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/file.rewrite.pcm %s -I%t -verify -fno-modules-error-recovery -DFILE_REWRITE
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/file.rewrite.pcm %s -I%t -verify -fno-modules-error-recovery -DFILE_REWRITE -DINCLUDE -I%S/Inputs/preprocess
Retain header search and preprocessing options from AST file when emitting preprocessed text for an AST file. llvm-svn: 304756
2017-06-06 08:32:01 +08:00
//
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
2017-06-27 03:39:25 +08:00
// Check that we can preprocess this user of the .pcm file.
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/file.pcm %s -I%t -E -frewrite-imports -o %t/preprocess-module.ii
// RUN: %clang_cc1 -fmodules %t/preprocess-module.ii -verify -fno-modules-error-recovery -DFILE_REWRITE_FULL
//
Retain header search and preprocessing options from AST file when emitting preprocessed text for an AST file. llvm-svn: 304756
2017-06-06 08:32:01 +08:00
// Check that language / header search options are ignored when preprocessing from a .pcm file.
// RUN: %clang_cc1 %t/file.pcm -E -frewrite-includes -o %t/file.rewrite.ii.2
// RUN: cmp %t/file.rewrite.ii %t/file.rewrite.ii.2
//
// RUN: %clang_cc1 -fmodules -fmodule-name=file -fmodule-file=%t/fwd.pcm -I%S/Inputs/preprocess %t/file.pcm -E -o %t/file.no-rewrite.ii
// RUN: %clang_cc1 %t/file.pcm -E -o %t/file.no-rewrite.ii.2 -Dstruct=error
// RUN: cmp %t/file.no-rewrite.ii %t/file.no-rewrite.ii.2
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
2017-06-06 02:10:11 +08:00
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
2017-05-06 06:18:51 +08:00
// == module map
// CHECK: # 1 "{{.*}}module.modulemap"
// CHECK: module file {
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
2017-06-02 09:55:39 +08:00
// CHECK: header "file.h" { size
// CHECK: header "file2.h" { size
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
2017-05-06 06:18:51 +08:00
// CHECK: }
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
2017-05-04 08:29:54 +08:00
// == file.h
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
2017-04-28 09:49:42 +08:00
// CHECK: # 1 "<module-includes>"
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
2017-05-04 08:29:54 +08:00
// REWRITE: #if 0
// REWRITE: #include "file.h"
// REWRITE: #endif
//
// FIXME: It would be preferable to consistently put the module begin/end in
// the same file, but the relative ordering of PP callbacks and module
// begin/end tokens makes that difficult.
//
// REWRITE: #pragma clang module begin file
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
2017-04-28 09:49:42 +08:00
// CHECK: # 1 "{{.*}}file.h" 1
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
2017-05-04 08:29:54 +08:00
// NO-REWRITE: #pragma clang module begin file
//
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
2017-06-27 03:39:25 +08:00
// REWRITE: #ifndef FILE_H
// REWRITE: #define FILE_H
//
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
2017-05-04 08:29:54 +08:00
// CHECK: #pragma clang module import fwd /* clang {{-E|-frewrite-includes}}: implicit import
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
2017-04-28 09:49:42 +08:00
// CHECK: typedef struct __FILE FILE;
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
2017-05-04 08:29:54 +08:00
//
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
2017-06-27 03:39:25 +08:00
// REWRITE: #endif
//
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
2017-05-04 08:29:54 +08:00
// REWRITE: #pragma clang module end
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
2017-04-28 09:49:42 +08:00
// CHECK: # 2 "<module-includes>" 2
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
2017-05-04 08:29:54 +08:00
// NO-REWRITE: #pragma clang module end
// == file2.h
// REWRITE: #if 0
// REWRITE: #include "file2.h"
// REWRITE: #endif
//
// REWRITE: #pragma clang module begin file
// CHECK: # 1 "{{.*}}file2.h" 1
// NO-REWRITE: #pragma clang module begin file
//
// ==== recursively re-enter file.h
// REWRITE: #if 0
// REWRITE: #include "file.h"
// REWRITE: #endif
//
// REWRITE: #pragma clang module begin file
// CHECK: # 1 "{{.*}}file.h" 1
// NO-REWRITE: #pragma clang module begin file
//
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
2017-06-27 03:39:25 +08:00
// REWRITE: #ifndef FILE_H
// REWRITE: #define FILE_H
// REWRITE: #if 0
// REWRITE: #include "fwd.h"
// REWRITE: #endif
// REWRITE-NOT: #pragma clang module import fwd
// REWRITE: #endif
//
// NO-REWRITE-NOT: struct __FILE;
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
2017-05-04 08:29:54 +08:00
//
// REWRITE: #pragma clang module end
// CHECK: # 2 "{{.*}}file2.h" 2
// NO-REWRITE: #pragma clang module end
// NO-REWRITE: # 2 "{{.*}}file2.h"{{$}}
// ==== return to file2.h
//
// CHECK: extern int file2;
//
// REWRITE: #pragma clang module end
// CHECK: # 3 "<module-includes>" 2
// NO-REWRITE: #pragma clang module end
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
2017-05-06 06:18:51 +08:00
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
2017-06-27 03:39:25 +08:00
__FILE *a; // expected-error-re {{{{declaration of '__FILE' must be imported|unknown type name '__FILE'}}}}
Attempt to fix Windows buildbot failure due to mismatching directory separators in preprocessed output. llvm-svn: 304727
2017-06-06 02:39:31 +08:00
#if FILE_REWRITE
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
2017-06-27 03:39:25 +08:00
// expected-note@file.rewrite.ii:* {{here}}
#elif FILE_REWRITE_FULL
// No note diagnostic at all in this case: we've built the 'file' module but not loaded it into this compilation yet.
Attempt to fix Windows buildbot failure due to mismatching directory separators in preprocessed output. llvm-svn: 304727
2017-06-06 02:39:31 +08:00
#elif REWRITE
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
2017-06-27 03:39:25 +08:00
// expected-note@rewrite.ii:* {{here}}
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
2017-06-02 09:55:39 +08:00
#elif COPY
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
2017-06-27 03:39:25 +08:00
// expected-note@copy.ii:* {{here}}
[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
2017-05-18 10:29:20 +08:00
#else
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
2017-06-27 03:39:25 +08:00
// expected-note@no-rewrite.ii:* {{here}}
[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
2017-05-18 10:29:20 +08:00
#endif
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
2017-05-06 06:18:51 +08:00
[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
2017-06-01 04:56:55 +08:00
#ifdef INCLUDE
#include "file.h"
#else
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
2017-05-06 06:18:51 +08:00
#pragma clang module import file
[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
2017-06-01 04:56:55 +08:00
#endif
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
2017-05-06 06:18:51 +08:00
FILE *b;
[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
2017-06-01 04:56:55 +08:00
int x = file2; // ok, found in file2.h, even under -DINCLUDE