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

115 lines
3.9 KiB
C++
Raw Normal View History

[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: rm -rf %t
// RUN: cd %S
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m00 -o %t/m00.pcm \
// RUN: Inputs/stress1/module.modulemap
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m00 -o %t/m00_check.pcm \
// RUN: Inputs/stress1/module.modulemap
//
[Modules] A second attempt at writing out on-disk hash tables for the decl context lookup tables. The first attepmt at this caused problems. We had significantly more sources of non-determinism that I realized at first, and my change essentially turned them from non-deterministic output into use-after-free. Except that they weren't necessarily caught by tools because the data wasn't really freed. The new approach is much simpler. The first big simplification is to inline the "visit" code and handle this directly. That works much better, and I'll try to go and clean up the other caller of the visit logic similarly. The second key to the entire approach is that we need to *only* collect names into a stable order at first. We then need to issue all of the actual 'lookup()' calls in the stable order of the names so that we load external results in a stable order. Once we have loaded all the results, the table of results will stop being invalidated and we can walk all of the names again and use the cheap 'noload_lookup()' method to quickly get the results and serialize them. To handle constructors and conversion functions (whose names can't be stably ordered) in this approach, what we do is record only the visible constructor and conversion function names at first. Then, if we have any, we walk the decls of the class and add those names in the order they occur in the AST. The rest falls out naturally. This actually ends up simpler than the previous approach and seems much more robust. It uncovered a latent issue where we were building on-disk hash tables for lookup results when the context was a linkage spec! This happened to dodge all of the assert by some miracle. Instead, add a proper predicate to the DeclContext class and use that which tests both for function contexts and linkage specs. It also uncovered PR23030 where we are forming somewhat bizarre negative lookup results. I've just worked around this with a FIXME in place because fixing this particular Clang bug seems quite hard. I've flipped the first part of the test case I added for stability back on in this commit. I'm taking it gradually to try and make sure the build bots are happy this time. llvm-svn: 233249
2015-03-26 11:11:40 +08:00
// RUN: diff %t/m00.pcm %t/m00_check.pcm
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
//
[Modules] Preserve source order for the map of late parsed templates. Clang was inserting these into a dense map. While it never iterated the dense map during normal compilation, it did when emitting a module. Fix this by using a standard MapVector to preserve the order in which we encounter the late parsed templates. I suspect this still isn't ideal, as we don't seem to remove things from this map even when we mark the templates as no longer late parsed. But I don't know enough about this particular extension to craft a nice, subtle test case covering this. I've managed to get the stress test to at least do some late parsing and demonstrate the core problem here. This patch fixes the test and provides deterministic behavior which is a strict improvement over the prior state. I've cleaned up some of the code here as well to be explicit about inserting when that is what is actually going on. llvm-svn: 233264
2015-03-26 17:08:15 +08:00
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 -fdelayed-template-parsing \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m01 -o %t/m01.pcm \
// RUN: Inputs/stress1/module.modulemap
//
[Modules] Preserve source order for the map of late parsed templates. Clang was inserting these into a dense map. While it never iterated the dense map during normal compilation, it did when emitting a module. Fix this by using a standard MapVector to preserve the order in which we encounter the late parsed templates. I suspect this still isn't ideal, as we don't seem to remove things from this map even when we mark the templates as no longer late parsed. But I don't know enough about this particular extension to craft a nice, subtle test case covering this. I've managed to get the stress test to at least do some late parsing and demonstrate the core problem here. This patch fixes the test and provides deterministic behavior which is a strict improvement over the prior state. I've cleaned up some of the code here as well to be explicit about inserting when that is what is actually going on. llvm-svn: 233264
2015-03-26 17:08:15 +08:00
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 -fdelayed-template-parsing \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Preserve source order for the map of late parsed templates. Clang was inserting these into a dense map. While it never iterated the dense map during normal compilation, it did when emitting a module. Fix this by using a standard MapVector to preserve the order in which we encounter the late parsed templates. I suspect this still isn't ideal, as we don't seem to remove things from this map even when we mark the templates as no longer late parsed. But I don't know enough about this particular extension to craft a nice, subtle test case covering this. I've managed to get the stress test to at least do some late parsing and demonstrate the core problem here. This patch fixes the test and provides deterministic behavior which is a strict improvement over the prior state. I've cleaned up some of the code here as well to be explicit about inserting when that is what is actually going on. llvm-svn: 233264
2015-03-26 17:08:15 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m01 -o %t/m01_check.pcm \
// RUN: Inputs/stress1/module.modulemap
//
// RUN: diff %t/m01.pcm %t/m01_check.pcm
//
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m02 -o %t/m02.pcm \
// RUN: Inputs/stress1/module.modulemap
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -emit-module -fmodule-name=m03 -o %t/m03.pcm \
// RUN: Inputs/stress1/module.modulemap
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -fmodule-file=%t/m00.pcm \
// RUN: -fmodule-file=%t/m01.pcm \
// RUN: -fmodule-file=%t/m02.pcm \
// RUN: -fmodule-file=%t/m03.pcm \
// RUN: -emit-module -fmodule-name=merge00 -o %t/merge00.pcm \
// RUN: Inputs/stress1/module.modulemap
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -fmodule-file=%t/m00.pcm \
// RUN: -fmodule-file=%t/m01.pcm \
// RUN: -fmodule-file=%t/m02.pcm \
// RUN: -fmodule-file=%t/m03.pcm \
// RUN: -emit-module -fmodule-name=merge00 -o %t/merge00_check.pcm \
// RUN: Inputs/stress1/module.modulemap
//
[Modules] Delete a bunch of complex code for ensuring visible decls in updated decl contexts get emitted. Since this code was added, we have newer vastly simpler code for handling this. The code I'm removing was very expensive and also generated unstable order of declarations which made module outputs non-deterministic. All of the tests continue to pass for me and I'm able to check the difference between the .pcm files after merging modules together. llvm-svn: 233251
2015-03-26 12:27:10 +08:00
// RUN: diff %t/merge00.pcm %t/merge00_check.pcm
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -fmodule-map-file=Inputs/stress1/module.modulemap \
// RUN: -fmodule-file=%t/m00.pcm \
// RUN: -fmodule-file=%t/m01.pcm \
// RUN: -fmodule-file=%t/m02.pcm \
// RUN: -fmodule-file=%t/m03.pcm \
// RUN: -fmodule-file=%t/merge00.pcm \
// RUN: -verify stress1.cpp -S -emit-llvm -o %t/stress1.ll
//
// RUN: %clang_cc1 -fmodules -x c++ -std=c++11 \
// RUN: -I Inputs/stress1 \
[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: -fno-implicit-modules \
[Modules] Make the DeclUpdates map be processed in insertion order. This fixes my stress tests non-determinism so far. However, I've not started playing with templates, friends, or terrible macros. I've found at least two more seeming instabilities and am just waiting for a test case to actually trigger them. llvm-svn: 233162
2015-03-25 09:02:12 +08:00
// RUN: -fmodule-map-file-home-is-cwd \
// RUN: -fmodule-map-file=Inputs/stress1/module.modulemap \
// RUN: -fmodule-file=%t/m00.pcm \
// RUN: -fmodule-file=%t/m01.pcm \
// RUN: -fmodule-file=%t/m02.pcm \
// RUN: -fmodule-file=%t/m03.pcm \
// RUN: -fmodule-file=%t/merge00.pcm \
// RUN: -verify stress1.cpp -S -emit-llvm -o %t/stress1_check.ll
//
// RUN: diff -u %t/stress1.ll %t/stress1_check.ll
//
// expected-no-diagnostics
#include "m00.h"
#include "m01.h"
#include "m02.h"
#include "m03.h"
#include "merge00.h"
int f() { return N01::S00('a').method00('b') + (int)N00::S00(42) + function00(42) + g(); }
[Modules] Make "#pragma weak" undeclared identifiers be tracked deterministically. This fixes a latent issue where even Clang's Sema (and diagnostics) were non-deterministic in the face of this pragma. The fix is super simple -- just use a MapVector so we track the order in which these are parsed (or imported). Especially considering how rare they are, this seems like the perfect tradeoff. I've also simplified the client code with judicious use of auto and range based for loops. I've added some pretty hilarious code to my stress test which now survives the binary diff without issue. llvm-svn: 233261
2015-03-26 16:32:49 +08:00
int f2() {
return pragma_weak00() + pragma_weak01() + pragma_weak02() +
pragma_weak03 + pragma_weak04 + pragma_weak05;
}