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/empty.modulemap

21 lines
732 B
Plaintext
Raw Normal View History

[Modules] Start making explicit modules produce deterministic output. There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
2015-03-25 05:18:10 +08:00
// RUN: rm -rf %t
//
// RUN: %clang_cc1 -fmodules -x c++ -fmodules-cache-path=%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: -fno-implicit-modules \
[Modules] Start making explicit modules produce deterministic output. There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
2015-03-25 05:18:10 +08:00
// RUN: -emit-module -fmodule-name=empty -o %t/base.pcm \
// RUN: %s
//
// RUN: %clang_cc1 -fmodules -x c++ -fmodules-cache-path=%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: -fno-implicit-modules \
[Modules] Start making explicit modules produce deterministic output. There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
2015-03-25 05:18:10 +08:00
// RUN: -emit-module -fmodule-name=empty -o %t/check.pcm \
// RUN: %s
//
[modules] Don't save uninteresting identifiers, and don't consider identifiers to be interesting just because they are the name of a builtin. Reduces the size of an empty module by over 80% (~100KB). llvm-svn: 242650
2015-07-20 05:41:12 +08:00
// The module file should be identical each time we produce it.
[Modules] Start making explicit modules produce deterministic output. There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
2015-03-25 05:18:10 +08:00
// RUN: diff %t/base.pcm %t/check.pcm
[modules] Don't save uninteresting identifiers, and don't consider identifiers to be interesting just because they are the name of a builtin. Reduces the size of an empty module by over 80% (~100KB). llvm-svn: 242650
2015-07-20 05:41:12 +08:00
//
Attempt to fix greendragon buildbot failures; apparently wc sometimes inserts a leading space into its output. Just check for a matching number anywhere in the output. llvm-svn: 242661
2015-07-20 16:40:51 +08:00
// We expect an empty module to be less than 30KB (and at least 10K, for now).
[modules] Don't save uninteresting identifiers, and don't consider identifiers to be interesting just because they are the name of a builtin. Reduces the size of an empty module by over 80% (~100KB). llvm-svn: 242650
2015-07-20 05:41:12 +08:00
// RUN: wc -c %t/base.pcm | FileCheck --check-prefix=CHECK-SIZE %s
Attempt to fix greendragon buildbot failures; apparently wc sometimes inserts a leading space into its output. Just check for a matching number anywhere in the output. llvm-svn: 242661
2015-07-20 16:40:51 +08:00
// CHECK-SIZE: {{(^|[^0-9])[12][0-9][0-9][0-9][0-9]($|[^0-9])}}
[Modules] Start making explicit modules produce deterministic output. There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
2015-03-25 05:18:10 +08:00
module empty { header "Inputs/empty.h" export * }