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

102 lines
3.6 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.
// FIXME: For now, we need the headers to exist.
// RUN: touch %t/file.h %t/file2.h
// 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
// Check the module we built works.
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/no-rewrite.pcm %s -verify
// RUN: %clang_cc1 -fmodules -fmodule-file=%t/rewrite.pcm %s -verify
// == module map
// CHECK: # 1 "{{.*}}module.modulemap"
// CHECK: module file {
// CHECK: header "file.h"
// CHECK: header "file2.h"
// 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
// NO-REWRITE: # 1 "{{.*}}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: 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
// 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
//
// 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
// NO-REWRITE: # 1 "{{.*}}file.h"{{$}}
//
// CHECK: struct __FILE;
// CHECK: #pragma clang module import fwd /* clang {{-E|-frewrite-includes}}: implicit import
// CHECK: typedef struct __FILE FILE;
//
// 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
// expected-no-diagnostics
// FIXME: This should be rejected: we have not imported the submodule defining it yet.
__FILE *a;
#pragma clang module import file
FILE *b;
int x = file2;