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/implementation-of-module.m

26 lines
1.5 KiB
Mathematica
Raw Normal View History

Add stopgap option -fmodule-implementation-of <name> This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
2014-07-23 23:30:23 +08:00
// RUN: rm -rf %t
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -w -Werror=auto-import %s -I %S/Inputs \
Keep -fmodule-implementation-of as an alias of -fmodule-name. This helps us transitioning to -fmodule-name. Once the transitioning is done, we can remove this alias. rdar://24800983 llvm-svn: 265616
2016-04-07 07:28:26 +08:00
// RUN: -fmodule-implementation-of category_right -fsyntax-only
Add stopgap option -fmodule-implementation-of <name> This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
2014-07-23 23:30:23 +08:00
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -w -Werror=auto-import %s -I %S/Inputs \
Keep -fmodule-implementation-of as an alias of -fmodule-name. This helps us transitioning to -fmodule-name. Once the transitioning is done, we can remove this alias. rdar://24800983 llvm-svn: 265616
2016-04-07 07:28:26 +08:00
// RUN: -fmodule-implementation-of category_right -dM -E -o - 2>&1 | FileCheck %s
Add stopgap option -fmodule-implementation-of <name> This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
2014-07-23 23:30:23 +08:00
// CHECK-NOT: __building_module
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -w -Werror=auto-import %s -I %S/Inputs \
Keep -fmodule-implementation-of as an alias of -fmodule-name. This helps us transitioning to -fmodule-name. Once the transitioning is done, we can remove this alias. rdar://24800983 llvm-svn: 265616
2016-04-07 07:28:26 +08:00
// RUN: -fmodule-implementation-of category_left -verify
Add stopgap option -fmodule-implementation-of <name> This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
2014-07-23 23:30:23 +08:00
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: %clang_cc1 -x objective-c-header -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -w -Werror=auto-import %s -I %S/Inputs \
Keep -fmodule-implementation-of as an alias of -fmodule-name. This helps us transitioning to -fmodule-name. Once the transitioning is done, we can remove this alias. rdar://24800983 llvm-svn: 265616
2016-04-07 07:28:26 +08:00
// RUN: -fmodule-implementation-of category_right -emit-pch -o %t.pch
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: %clang_cc1 -x objective-c-header -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -w -Werror=auto-import %s -I %S/Inputs \
Keep -fmodule-implementation-of as an alias of -fmodule-name. This helps us transitioning to -fmodule-name. Once the transitioning is done, we can remove this alias. rdar://24800983 llvm-svn: 265616
2016-04-07 07:28:26 +08:00
// RUN: -DWITH_PREFIX -fmodules-ignore-macro=WITH_PREFIX -include-pch %t.pch -fmodule-implementation-of category_right
Add stopgap option -fmodule-implementation-of <name> This flag specifies that we are building an implementation file of the module <name>, preventing importing <name> as a module. This does not consider this to be the 'current module' for the purposes of doing modular checks like decluse or non-modular-include warnings, unlike -fmodule-name. This is needed as a stopgap until: 1) we can resolve relative includes to a VFS-mapped module (or can safely import a header textually and as part of a module) and ideally 2) we can safely do incremental rebuilding when implementation files import submodules. llvm-svn: 213767
2014-07-23 23:30:23 +08:00
#ifndef WITH_PREFIX
@import category_left; // expected-error{{@import of module 'category_left' in implementation of 'category_left'; use #import}}
@import category_left.sub; // expected-error{{@import of module 'category_left.sub' in implementation of 'category_left'; use #import}}
#import "category_right.h" // expected-error{{treating}}
#import "category_right_sub.h" // expected-error{{treating}}
#endif