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/modular_maps.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

20 lines
1.5 KiB
C++
Raw Normal View History

Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
// RUN: rm -rf %t
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
//
[modules] Re-enable accidentally-disabled test. llvm-svn: 239783
2015-06-16 07:39:16 +08:00
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=%S/Inputs/modular_maps/modulea.map -fmodule-map-file=%S/Inputs/modular_maps/modulec.map -I %S/Inputs/modular_maps %s -verify
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=%S/Inputs/modular_maps/modulec.map -fmodule-map-file=%S/Inputs/modular_maps/modulea.map -I %S/Inputs/modular_maps %s -verify
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
//
[modules] Re-enable accidentally-disabled test. llvm-svn: 239783
2015-06-16 07:39:16 +08:00
// RUN: cd %S
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=Inputs/modular_maps/modulea.map -fmodule-map-file=Inputs/modular_maps/modulec.map -I Inputs/modular_maps %s -verify
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=Inputs/modular_maps/modulec.map -fmodule-map-file=Inputs/modular_maps/modulea.map -I Inputs/modular_maps %s -verify
Reinstate r223753, reverted in r223759 due to breakage of clang-tools-extra. Original commit message: [modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1. For files named by -fmodule-map-file=, and files found by 'extern module' directives, this flag specifies that we should resolve filenames relative to the current working directory rather than relative to the directory in which the module map file resides. This is aimed at fixing path handling, in particular for relative -I paths, when building modules that represent components of the current project (rather than libraries installed on the current system, which the current project has as dependencies, where we'd typically expect the module map files to be looked up implicitly). llvm-svn: 223913
2014-12-10 11:09:48 +08:00
//
// RUN: cd %S
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=Inputs/modular_maps/modulea-cwd.map -fmodule-map-file=Inputs/modular_maps/modulec-cwd.map -I Inputs/modular_maps %s -verify -fmodule-map-file-home-is-cwd
[modules] Re-enable accidentally-disabled test. llvm-svn: 239783
2015-06-16 07:39:16 +08:00
// RUN: %clang_cc1 -x objective-c++ -fmodules-cache-path=%t -fmodules -fmodule-map-file=Inputs/modular_maps/modulec-cwd.map -fmodule-map-file=Inputs/modular_maps/modulea-cwd.map -I Inputs/modular_maps %s -verify -fmodule-map-file-home-is-cwd
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
Allow a header to be part of multiple modules. This patch changes two things: a) Allow a header to be part of multiple modules. The reasoning is that in existing codebases that have a module-like build system, the same headers might be used in several build targets. Simple reasons might be that they defined different classes that are declared in the same header. Supporting a header as a part of multiple modules will make the transistion easier for those cases. A later step in clang can then determine whether the two modules are actually compatible and can be merged and error out appropriately. The later check is similar to what needs to be done for template specializations anyway. b) Allow modules to be stored in a directory tree separate from the headers they describe. Review: http://llvm-reviews.chandlerc.com/D1951 llvm-svn: 193151
2013-10-22 16:09:47 +08:00
#include "common.h"
Support for modular module-map-files This patch is the first step to make module-map-files modular (instead of requiring a single "module.map"-file per include directory). This step adds a new "extern module" declaration that enables module-map-files to reference one another along with a very basic implementation. The next steps are: * Combine this with the use-declaration (from http://llvm-reviews.chandlerc.com/D1546) in order to only load module map files required for a specific compilation. * Add an additional flag to start with a specific module-map-file (instead of requiring there to be at least one "module.map"). Review: http://llvm-reviews.chandlerc.com/D1637 llvm-svn: 190497
2013-09-11 15:20:44 +08:00
#include "a.h"
#include "b.h" // expected-error {{private header}}
PR21215: Support -fmodule-map-file being specified multiple times. Support loading multiple module map files from the same directory. llvm-svn: 220020
2014-10-17 09:42:53 +08:00
@import C;
const int v = a + c + x;
[modules] Make sure we always include the contents of private headers when building a module. Prior to this change, the private header's content would only be included if the header were included by another header in the same module. If not (if the private header is only used by the .cc files of the module, or is included from outside the module via -Wno-private-header), a #include of that file would be silently ignored. llvm-svn: 257222
2016-01-09 06:36:45 +08:00
const int val = a + b + c + x;