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/epic-fail.m

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

14 lines
550 B
Mathematica
Raw Normal View History

Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +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: not %clang_cc1 -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -F %S/Inputs -DgetModuleVersion="epic fail" %s 2>&1 | FileCheck %s
Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +08:00
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 Module;
@import DependsOnModule;
Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +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 'Module' imported from
Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +08:00
// CHECK: error: expected ';' after top level declarator
PR14049: Don't say "expanded from macro 'foo'" when 'foo' just happens to be the LHS of a token paste. Use "expanded from here" instead when we're not sure it's actually a macro. llvm-svn: 169373
2012-12-05 19:04:55 +08:00
// CHECK: note: expanded from here
Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +08:00
// CHECK: fatal error: could not build module 'Module'
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 'DependsOnModule' imported from
Keep track of modules that have failed to build. If we encounter an import of that module elsewhere, don't try to build the module again: it won't work, and the experience is quite dreadful. We track this information somewhat globally, shared among all of the related CompilerInvocations used to build modules on-the-fly, so that a particular Clang instance will only try to build a given module once. Fixes <rdar://problem/12552849>. llvm-svn: 168961
2012-11-30 07:55:25 +08:00
// CHECK: fatal error: could not build module 'Module'
// CHECK-NOT: error: