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/cycles.c

14 lines
712 B
C
Raw Normal View History

Add test case for mutually recursive modules llvm-svn: 139838
2011-09-16 04:54:06 +08:00
// RUN: rm -rf %t
Rename -fmodule-cache-path <blah> to -fmodules-cache-path=<blah> for consistency. llvm-svn: 174645
2013-02-08 03:01:24 +08:00
// RUN: %clang_cc1 -fmodules -x objective-c -fmodules-cache-path=%t -F %S/Inputs %s 2>&1 | FileCheck %s
Eliminate the uglified keyword __import_module__ for importing modules. This leaves us without an explicit syntax for importing modules in C/C++, because such a syntax needs to be discussed first. In Objective-C/Objective-C++, the @import syntax is used to import modules. Note that, under -fmodules, C/C++ programs can import modules via the #include mechanism when a module map is in place for that header. This allows us to work with modules in C/C++ without committing to a syntax. llvm-svn: 147467
2012-01-04 03:32:59 +08:00
// FIXME: When we have a syntax for modules in C, use that.
Use @import rather than @__experimental_modules_import, since the latter is rather a mess to type. llvm-svn: 169919
2012-12-12 06:11:52 +08:00
@import MutuallyRecursive1;
Add test case for mutually recursive modules llvm-svn: 139838
2011-09-16 04:54:06 +08:00
When an error occurs while building a module on demand, provide "While building module 'Foo' imported from..." notes (the same we we provide "In file included from..." notes) in the diagnostic, so that we know how this module got included in the first place. This is part of <rdar://problem/12696425>. llvm-svn: 169021
2012-12-01 02:38:50 +08:00
// CHECK: While building module 'MutuallyRecursive1' imported from
// CHECK: While building module 'MutuallyRecursive2' imported from
Use @import rather than @__experimental_modules_import, since the latter is rather a mess to type. llvm-svn: 169919
2012-12-12 06:11:52 +08:00
// CHECK: MutuallyRecursive2.h:3:9: fatal error: cyclic dependency in module 'MutuallyRecursive1': MutuallyRecursive1 -> MutuallyRecursive2 -> MutuallyRecursive1
// CHECK: MutuallyRecursive1.h:2:9: fatal error: could not build module 'MutuallyRecursive2'
// CHECK: cycles.c:4:9: fatal error: could not build module 'MutuallyRecursive1'
When building a module, forward diagnostics to the outer diagnostic consumer. Previously, we would clone the current diagnostic consumer to produce a new diagnostic consumer to use when building a module. The problem here is that we end up losing diagnostics for important diagnostic consumers, such as serialized diagnostics (where we'd end up with two diagnostic consumers writing the same output file). With forwarding, the diagnostics from all of the different modules being built get forwarded to the one serialized-diagnostic consumer and are emitted in a sane way. Fixes <rdar://problem/13663996>. llvm-svn: 181067
2013-05-04 06:58:43 +08:00
// CHECK: 3 errors generated
Add test case for mutually recursive modules llvm-svn: 139838
2011-09-16 04:54:06 +08:00