llvm-project/clang/test/Modules/declare-use1.cpp

// RUN: rm -rf %t
// RUN: %clang_cc1 -fmodule-maps -fmodules-cache-path=%t -fmodules-decluse -fmodule-name=XG -I %S/Inputs/declare-use %s -verify

#include "g.h"
#include "e.h"
#include "f.h" // expected-error {{module XG does not depend on a module exporting 'f.h'}}
const int g2 = g1+e+f;
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283 2013-09-24 09:14:14 +00:00			`// RUN: rm -rf %t`
Change layering warning tests to not actually build modules. Specifically, we want to warn only for direct layering violations for the modules we are calling clang on. This temporarily unblocks http://llvm-reviews.chandlerc.com/D2374 Once that is in, we'll also want to investigate whether to check the layering in the build step of modules that we build transitively. llvm-svn: 197021 2013-12-11 09:11:12 +00:00			`// RUN: %clang_cc1 -fmodule-maps -fmodules-cache-path=%t -fmodules-decluse -fmodule-name=XG -I %S/Inputs/declare-use %s -verify`
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283 2013-09-24 09:14:14 +00:00
			`#include "g.h"`
			`#include "e.h"`
Allow string literals as module names. In order to make the migration to modules easier, it seems to be helpful to allow a 1:1 mapping between target names of a current build system and the corresponding C++ modules. As such targets commonly contain characters like "-". ":" and "/", allowing arbitrary quote-escaped strings seems to be a straightforward option. After several offline discussions, the precise mechanisms for C++ module names especially regarding submodules and import statements has yet to be determined. Thus, this patch only enables string literals as names inside the module map files which can be used by automatic module import (through #include). Also improve the error message on missing use-declarations. llvm-svn: 196573 2013-12-06 09:25:54 +00:00			`#include "f.h" // expected-error {{module XG does not depend on a module exporting 'f.h'}}`
Module use declarations (II) Review: http://llvm-reviews.chandlerc.com/D1546. I have picked up this patch form Lawrence (http://llvm-reviews.chandlerc.com/D1063) and did a few changes. From the original change description (updated as appropriate): This patch adds a check that ensures that modules only use modules they have so declared. To this end, it adds a statement on intended module use to the module.map grammar: use module-id A module can then only use headers from other modules if it 'uses' them. This enforcement is off by default, but may be turned on with the new option -fmodules-decluse. When enforcing the module semantics, we also need to consider a source file part of a module. This is achieved with a compiler option -fmodule-name=<module-id>. The compiler at present only applies restrictions to the module directly being built. llvm-svn: 191283 2013-09-24 09:14:14 +00:00			`const int g2 = g1+e+f;`