llvm-project/clang/test/lit.cfg.py

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

372 lines
11 KiB
Python
Raw Normal View History

# -*- Python -*-
import os
import platform
import re
import subprocess
[PCH] Remove the stat cache from the PCH file. The stat cache became essentially useless ever since we started validating all file entries in the PCH. But the motivating reason for removing it now is that it also affected correctness in this situation: -You have a header without include guards (using "#pragma once" or #import) -When creating the PCH: -The same header is referenced in an #include with different filename cases. -In the PCH, of course, we record only one file entry for the header file -But we cache in the PCH file the stat info for both filename cases -Then the source files are updated and the header file is updated in a way that its size and modification time are the same but its inode changes -When using the PCH: -We validate the headers, we check that header file and we create a file entry with its current inode -There's another #include with a filename with different case than the previously created file entry -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode -because of the different inodes, we think they are different files so we go ahead and include its contents. Removing the stat cache will potentially break clients that are attempting to use the stat cache as a way of avoiding having the actual input files available. If that use case is important, patches are welcome to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with literal strings, line/column computations, etc.). This fixes rdar://5502805 llvm-svn: 167172
2012-10-31 20:59:50 +00:00
import tempfile
import lit.formats
import lit.util
from lit.llvm import llvm_config
from lit.llvm.subst import ToolSubst
from lit.llvm.subst import FindTool
# Configuration file for the 'lit' test runner.
# name: The name of this test suite.
config.name = "Clang"
# testFormat: The test format to use to interpret tests.
#
# For now we require '&&' between commands, until they get globally killed and
# the test runner updated.
config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
# suffixes: A list of file extensions to treat as test files.
config.suffixes = [
".c",
".cpp",
".i",
".cir",
".cppm",
".m",
".mm",
".cu",
".cuh",
".hip",
".hlsl",
".ll",
".cl",
".clcpp",
".s",
".S",
".modulemap",
".test",
".rs",
".ifs",
".rc",
]
# excludes: A list of directories to exclude from the testsuite. The 'Inputs'
# subdirectories contain auxiliary inputs for various tests in their parent
# directories.
config.excludes = [
"Inputs",
"CMakeLists.txt",
"README.txt",
"LICENSE.txt",
"debuginfo-tests",
]
# test_source_root: The root path where tests are located.
config.test_source_root = os.path.dirname(__file__)
# test_exec_root: The root path where tests should be run.
config.test_exec_root = os.path.join(config.clang_obj_root, "test")
llvm_config.use_default_substitutions()
llvm_config.use_clang()
Fix some issues with LLDB's lit configuration files. Recently I tried to port LLDB's lit configuration files over to use a on the surface, but broke some cases that weren't broken before and also exposed some additional problems with the old approach that we were just getting lucky with. When we set up a lit environment, the goal is to make it as hermetic as possible. We should not be relying on PATH and enabling the use of arbitrary shell commands. Instead, only whitelisted commands should be allowed. These are, generally speaking, the lit builtins such as echo, cd, etc, as well as anything for which substitutions have been explicitly set up for. These substitutions should map to the build output directory, but in some cases it's useful to be able to override this (for example to point to an installed tools directory). This is, of course, how it's supposed to work. What was actually happening is that we were bringing in PATH and LD_LIBRARY_PATH and then just running the given run line as a shell command. This led to problems such as finding the wrong version of clang-cl on PATH since it wasn't even a substitution, and flakiness / non-determinism since the environment the tests were running in would change per-machine. On the other hand, it also made other things possible. For example, we had some tests that were explicitly running cl.exe and link.exe instead of clang-cl and lld-link and the only reason it worked at all is because it was finding them on PATH. Unfortunately we can't entirely get rid of these tests, because they support a few things in debug info that clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record which makes some of the tests fail. The high level changes introduced in this patch are: 1. Removal of functionality - The lit test suite no longer respects LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no more support for gcc, but nobody was using this anyway (note: The functionality is still there for the dotest suite, just not the lit test suite). There is no longer a single substitution %cxx and %cc which maps to <arbitrary-compiler>, you now explicitly specify the compiler with a substitution like %clang or %clangxx or %clang_cl. We can revisit this in the future when someone needs gcc. 2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now more friendly. If this is not specified, all tools are expected to be the just-built tools. If it is specified, the tools which are not themselves being tested but are being used to construct and run checks (e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this directory first, then the build output directory. 3. Changes to core llvm lit files. The use_lld() and use_clang() functions were introduced long ago in anticipation of using them in lldb, but since they were never actually used anywhere but their respective problems, there were some issues to be resolved regarding generality and ability to use them outside their project. 4. Changes to .test files - These are all just replacing things like clang-cl with %clang_cl and %cxx with %clangxx, etc. 5. Changes to lit.cfg.py - Previously we would load up some system environment variables and then add some new things to them. Then do a bunch of work building out our own substitutions. First, we delete the system environment variable code, making the environment hermetic. Then, we refactor the substitution logic into two separate helper functions, one which sets up substitutions for the tools we want to test (which must come from the build output directory), and another which sets up substitutions for support tools (like compilers, etc). 6. New substitutions for MSVC -- Previously we relied on location of MSVC by bringing in the entire parent's PATH and letting subprocess.Popen just run the command line. Now we set up real substitutions that should have the same effect. We use PATH to find them, and then look for INCLUDE and LIB to construct a substitution command line with appropriate /I and /LIBPATH: arguments. The nice thing about this is that it opens the door to having separate %msvc-cl32 and %msvc-cl64 substitutions, rather than only requiring the user to run vcvars first. Because we can deduce the path to 32-bit libraries from 64-bit library directories, and vice versa. Without these substitutions this would have been impossible. Differential Revision: https://reviews.llvm.org/D54567 llvm-svn: 347216
2018-11-19 15:12:34 +00:00
config.substitutions.append(("%src_include_dir", config.clang_src_dir + "/include"))
config.substitutions.append(("%target_triple", config.target_triple))
Fix some issues with LLDB's lit configuration files. Recently I tried to port LLDB's lit configuration files over to use a on the surface, but broke some cases that weren't broken before and also exposed some additional problems with the old approach that we were just getting lucky with. When we set up a lit environment, the goal is to make it as hermetic as possible. We should not be relying on PATH and enabling the use of arbitrary shell commands. Instead, only whitelisted commands should be allowed. These are, generally speaking, the lit builtins such as echo, cd, etc, as well as anything for which substitutions have been explicitly set up for. These substitutions should map to the build output directory, but in some cases it's useful to be able to override this (for example to point to an installed tools directory). This is, of course, how it's supposed to work. What was actually happening is that we were bringing in PATH and LD_LIBRARY_PATH and then just running the given run line as a shell command. This led to problems such as finding the wrong version of clang-cl on PATH since it wasn't even a substitution, and flakiness / non-determinism since the environment the tests were running in would change per-machine. On the other hand, it also made other things possible. For example, we had some tests that were explicitly running cl.exe and link.exe instead of clang-cl and lld-link and the only reason it worked at all is because it was finding them on PATH. Unfortunately we can't entirely get rid of these tests, because they support a few things in debug info that clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record which makes some of the tests fail. The high level changes introduced in this patch are: 1. Removal of functionality - The lit test suite no longer respects LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no more support for gcc, but nobody was using this anyway (note: The functionality is still there for the dotest suite, just not the lit test suite). There is no longer a single substitution %cxx and %cc which maps to <arbitrary-compiler>, you now explicitly specify the compiler with a substitution like %clang or %clangxx or %clang_cl. We can revisit this in the future when someone needs gcc. 2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now more friendly. If this is not specified, all tools are expected to be the just-built tools. If it is specified, the tools which are not themselves being tested but are being used to construct and run checks (e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this directory first, then the build output directory. 3. Changes to core llvm lit files. The use_lld() and use_clang() functions were introduced long ago in anticipation of using them in lldb, but since they were never actually used anywhere but their respective problems, there were some issues to be resolved regarding generality and ability to use them outside their project. 4. Changes to .test files - These are all just replacing things like clang-cl with %clang_cl and %cxx with %clangxx, etc. 5. Changes to lit.cfg.py - Previously we would load up some system environment variables and then add some new things to them. Then do a bunch of work building out our own substitutions. First, we delete the system environment variable code, making the environment hermetic. Then, we refactor the substitution logic into two separate helper functions, one which sets up substitutions for the tools we want to test (which must come from the build output directory), and another which sets up substitutions for support tools (like compilers, etc). 6. New substitutions for MSVC -- Previously we relied on location of MSVC by bringing in the entire parent's PATH and letting subprocess.Popen just run the command line. Now we set up real substitutions that should have the same effect. We use PATH to find them, and then look for INCLUDE and LIB to construct a substitution command line with appropriate /I and /LIBPATH: arguments. The nice thing about this is that it opens the door to having separate %msvc-cl32 and %msvc-cl64 substitutions, rather than only requiring the user to run vcvars first. Because we can deduce the path to 32-bit libraries from 64-bit library directories, and vice versa. Without these substitutions this would have been impossible. Differential Revision: https://reviews.llvm.org/D54567 llvm-svn: 347216
2018-11-19 15:12:34 +00:00
config.substitutions.append(("%PATH%", config.environment["PATH"]))
# For each occurrence of a clang tool name, replace it with the full path to
# the build directory holding that tool. We explicitly specify the directories
# to search to ensure that we get the tools just built and not some random
# tools that might happen to be in the user's PATH.
tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
tools = [
"apinotes-test",
"c-index-test",
"cir-opt",
"clang-diff",
"clang-format",
"clang-repl",
"clang-offload-packager",
"clang-tblgen",
"clang-scan-deps",
"clang-installapi",
"opt",
"llvm-ifs",
"yaml2obj",
"clang-linker-wrapper",
[Clang] Introduce 'clang-nvlink-wrapper' to work around 'nvlink' (#96561) Summary: The `clang-nvlink-wrapper` is a utility that I removed awhile back during the transition to the new driver. This patch adds back in a new, upgraded version that does LTO + archive linking. It's not an easy choice to reintroduce something I happily deleted, but this is the only way to move forward with improving GPU support in LLVM. While NVIDIA provides a linker called 'nvlink', its main interface is very difficult to work with. It does not provide LTO, or static linking, requires all files to be named a non-standard `.cubin`, and rejects link jobs that other linkers would be fine with (i.e empty). I have spent a great deal of time hacking around this in the GPU `libc` implementation, where I deliberately avoid LTO and static linking and have about 100 lines of hacky CMake dedicated to storing these files in a format that the clang-linker-wrapper accepts to avoid this limitation. The main reason I want to re-intorudce this tool is because I am planning on creating a more standard C/C++ toolchain for GPUs to use. This will install files like the following. ``` <install>/lib/nvptx64-nvidia-cuda/libc.a <install>/lib/nvptx64-nvidia-cuda/libc++.a <install>/lib/nvptx64-nvidia-cuda/libomp.a <install>/lib/clang/19/lib/nvptx64-nvidia-cuda/libclang_rt.builtins.a ``` Linking in these libraries will then simply require passing `-lc` like is already done for non-GPU toolchains. However, this doesn't work with the currently deficient `nvlink` linker, so I consider this a blocking issue to massively improving the state of building GPU libraries. In the future we may be able to convince NVIDIA to port their linker to `ld.lld`, but for now this is the only workable solution that allows us to hack around the weird behavior of their closed-source software. This also copies some amount of logic from the clang-linker-wrapper, but not enough for it to be worthwhile to merge them I feel. In the future it may be possible to delete that handling from there entirely.
2024-07-22 18:20:14 -05:00
"clang-nvlink-wrapper",
[Clang][SYCL] Introduce clang-sycl-linker to link SYCL offloading device code (Part 1 of many) (#112245) This PR is one of the many PRs in the SYCL upstreaming effort focusing on device code linking during the SYCL offload compilation process. RFC: https://discourse.llvm.org/t/rfc-offloading-design-for-sycl-offload-kind-and-spir-targets/74088 In this PR, we introduce a new tool that will be used to perform device code linking for SYCL offload kind. It accepts SYCL device objects in LLVM IR bitcode format and will generate a fully linked device object that can then be wrapped and linked into the host object. A primary use case for this tool is to perform device code linking for objects with SYCL offload kind inside the clang-linker-wrapper. It can also be invoked via clang driver as follows: `clang --target=spirv64 --sycl-link input.bc` Device code linking for SYCL offloading kind has a number of known quirks that makes it difficult to use in a unified offloading setting. Two of the primary issues are: 1. Several finalization steps are required to be run on the fully-linked LLVM IR bitcode to gaurantee conformance to SYCL standards. This step is unique to SYCL offloading compilation flow. 2. SPIR-V LLVM Translator tool is an extenal tool and hence SPIR-V IR code generation cannot be done as part of LTO. This limitation will be lifted once SPIR-V backend is available as a viable LLVM backend. Hence, we introduce this new tool to provide a clean wrapper to perform SYCL device linking. Co-Author: Michael Toguchi Thanks --------- Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
2024-10-31 07:39:55 -07:00
"clang-sycl-linker",
"llvm-lto",
"llvm-lto2",
"llvm-profdata",
"llvm-readtapi",
ToolSubst(
"%clang_extdef_map",
command=FindTool("clang-extdef-mapping"),
unresolved="ignore",
),
]
if config.clang_examples:
config.available_features.add("examples")
def have_host_jit_feature_support(feature_name):
[clang-repl] Recommit "Land initial infrastructure for incremental parsing" Original commit message: In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have mentioned our plans to make some of the incremental compilation facilities available in llvm mainline. This patch proposes a minimal version of a repl, clang-repl, which enables interpreter-like interaction for C++. For instance: ./bin/clang-repl clang-repl> int i = 42; clang-repl> extern "C" int printf(const char*,...); clang-repl> auto r1 = printf("i=%d\n", i); i=42 clang-repl> quit The patch allows very limited functionality, for example, it crashes on invalid C++. The design of the proposed patch follows closely the design of cling. The idea is to gather feedback and gradually evolve both clang-repl and cling to what the community agrees upon. The IncrementalParser class is responsible for driving the clang parser and codegen and allows the compiler infrastructure to process more than one input. Every input adds to the “ever-growing” translation unit. That model is enabled by an IncrementalAction which prevents teardown when HandleTranslationUnit. The IncrementalExecutor class hides some of the underlying implementation details of the concrete JIT infrastructure. It exposes the minimal set of functionality required by our incremental compiler/interpreter. The Transaction class keeps track of the AST and the LLVM IR for each incremental input. That tracking information will be later used to implement error recovery. The Interpreter class orchestrates the IncrementalParser and the IncrementalExecutor to model interpreter-like behavior. It provides the public API which can be used (in future) when using the interpreter library. Differential revision: https://reviews.llvm.org/D96033
2021-05-13 05:41:44 +00:00
clang_repl_exe = lit.util.which("clang-repl", config.clang_tools_dir)
if not clang_repl_exe:
return False
try:
clang_repl_cmd = subprocess.Popen(
[clang_repl_exe, "--host-supports-" + feature_name], stdout=subprocess.PIPE
)
[clang-repl] Recommit "Land initial infrastructure for incremental parsing" Original commit message: In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have mentioned our plans to make some of the incremental compilation facilities available in llvm mainline. This patch proposes a minimal version of a repl, clang-repl, which enables interpreter-like interaction for C++. For instance: ./bin/clang-repl clang-repl> int i = 42; clang-repl> extern "C" int printf(const char*,...); clang-repl> auto r1 = printf("i=%d\n", i); i=42 clang-repl> quit The patch allows very limited functionality, for example, it crashes on invalid C++. The design of the proposed patch follows closely the design of cling. The idea is to gather feedback and gradually evolve both clang-repl and cling to what the community agrees upon. The IncrementalParser class is responsible for driving the clang parser and codegen and allows the compiler infrastructure to process more than one input. Every input adds to the “ever-growing” translation unit. That model is enabled by an IncrementalAction which prevents teardown when HandleTranslationUnit. The IncrementalExecutor class hides some of the underlying implementation details of the concrete JIT infrastructure. It exposes the minimal set of functionality required by our incremental compiler/interpreter. The Transaction class keeps track of the AST and the LLVM IR for each incremental input. That tracking information will be later used to implement error recovery. The Interpreter class orchestrates the IncrementalParser and the IncrementalExecutor to model interpreter-like behavior. It provides the public API which can be used (in future) when using the interpreter library. Differential revision: https://reviews.llvm.org/D96033
2021-05-13 05:41:44 +00:00
except OSError:
print("could not exec clang-repl")
return False
clang_repl_out = clang_repl_cmd.stdout.read().decode("ascii")
clang_repl_cmd.wait()
return "true" in clang_repl_out
def have_host_clang_repl_cuda():
clang_repl_exe = lit.util.which('clang-repl', config.clang_tools_dir)
if not clang_repl_exe:
return False
testcode = b'\n'.join([
b"__global__ void test_func() {}",
b"test_func<<<1,1>>>();",
b"extern \"C\" int puts(const char *s);",
b"puts(cudaGetLastError() ? \"failure\" : \"success\");",
b"%quit"
])
try:
clang_repl_cmd = subprocess.run([clang_repl_exe, '--cuda'],
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
input=testcode)
except OSError:
return False
if clang_repl_cmd.returncode == 0:
if clang_repl_cmd.stdout.find(b"success") != -1:
return True
return False
if have_host_jit_feature_support('jit'):
config.available_features.add('host-supports-jit')
if have_host_clang_repl_cuda():
config.available_features.add('host-supports-cuda')
[clang-repl] Recommit "Land initial infrastructure for incremental parsing" Original commit message: In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have mentioned our plans to make some of the incremental compilation facilities available in llvm mainline. This patch proposes a minimal version of a repl, clang-repl, which enables interpreter-like interaction for C++. For instance: ./bin/clang-repl clang-repl> int i = 42; clang-repl> extern "C" int printf(const char*,...); clang-repl> auto r1 = printf("i=%d\n", i); i=42 clang-repl> quit The patch allows very limited functionality, for example, it crashes on invalid C++. The design of the proposed patch follows closely the design of cling. The idea is to gather feedback and gradually evolve both clang-repl and cling to what the community agrees upon. The IncrementalParser class is responsible for driving the clang parser and codegen and allows the compiler infrastructure to process more than one input. Every input adds to the “ever-growing” translation unit. That model is enabled by an IncrementalAction which prevents teardown when HandleTranslationUnit. The IncrementalExecutor class hides some of the underlying implementation details of the concrete JIT infrastructure. It exposes the minimal set of functionality required by our incremental compiler/interpreter. The Transaction class keeps track of the AST and the LLVM IR for each incremental input. That tracking information will be later used to implement error recovery. The Interpreter class orchestrates the IncrementalParser and the IncrementalExecutor to model interpreter-like behavior. It provides the public API which can be used (in future) when using the interpreter library. Differential revision: https://reviews.llvm.org/D96033
2021-05-13 05:41:44 +00:00
if config.clang_staticanalyzer:
config.available_features.add("staticanalyzer")
tools.append("clang-check")
if config.clang_staticanalyzer_z3:
config.available_features.add("z3")
else:
config.available_features.add("no-z3")
check_analyzer_fixit_path = os.path.join(
config.test_source_root, "Analysis", "check-analyzer-fixit.py"
)
config.substitutions.append(
(
"%check_analyzer_fixit",
'"%s" %s' % (config.python_executable, check_analyzer_fixit_path),
)
)
llvm_config.add_tool_substitutions(tools, tool_dirs)
config.substitutions.append(
(
"%hmaptool",
"'%s' %s"
% (
config.python_executable,
os.path.join(config.clang_src_dir, "utils", "hmaptool", "hmaptool"),
),
)
)
config.substitutions.append(
(
"%deps-to-rsp",
'"%s" %s'
% (
config.python_executable,
os.path.join(config.clang_src_dir, "utils", "module-deps-to-rsp.py"),
),
)
)
config.substitutions.append(("%host_cc", config.host_cc))
config.substitutions.append(("%host_cxx", config.host_cxx))
# Determine whether the test target is compatible with execution on the host.
if "aarch64" in config.host_arch:
config.available_features.add("aarch64-host")
# Plugins (loadable modules)
if config.has_plugins and config.llvm_plugin_ext:
config.available_features.add("plugins")
if config.clang_default_pie_on_linux:
config.available_features.add("default-pie-on-linux")
# Set available features we allow tests to conditionalize on.
#
if config.clang_default_cxx_stdlib != "":
config.available_features.add(
"default-cxx-stdlib={}".format(config.clang_default_cxx_stdlib)
)
# As of 2011.08, crash-recovery tests still do not pass on FreeBSD.
if platform.system() not in ["FreeBSD"]:
config.available_features.add("crash-recovery")
# ANSI escape sequences in non-dumb terminal
if platform.system() not in ["Windows"]:
config.available_features.add("ansi-escape-sequences")
# Capability to print utf8 to the terminal.
# Windows expects codepage, unless Wide API.
if platform.system() not in ["Windows"]:
config.available_features.add("utf8-capable-terminal")
# Support for libgcc runtime. Used to rule out tests that require
# clang to run with -rtlib=libgcc.
if platform.system() not in ["Darwin", "Fuchsia"]:
config.available_features.add("libgcc")
[PCH] Remove the stat cache from the PCH file. The stat cache became essentially useless ever since we started validating all file entries in the PCH. But the motivating reason for removing it now is that it also affected correctness in this situation: -You have a header without include guards (using "#pragma once" or #import) -When creating the PCH: -The same header is referenced in an #include with different filename cases. -In the PCH, of course, we record only one file entry for the header file -But we cache in the PCH file the stat info for both filename cases -Then the source files are updated and the header file is updated in a way that its size and modification time are the same but its inode changes -When using the PCH: -We validate the headers, we check that header file and we create a file entry with its current inode -There's another #include with a filename with different case than the previously created file entry -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode -because of the different inodes, we think they are different files so we go ahead and include its contents. Removing the stat cache will potentially break clients that are attempting to use the stat cache as a way of avoiding having the actual input files available. If that use case is important, patches are welcome to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with literal strings, line/column computations, etc.). This fixes rdar://5502805 llvm-svn: 167172
2012-10-31 20:59:50 +00:00
# Case-insensitive file system
[PCH] Remove the stat cache from the PCH file. The stat cache became essentially useless ever since we started validating all file entries in the PCH. But the motivating reason for removing it now is that it also affected correctness in this situation: -You have a header without include guards (using "#pragma once" or #import) -When creating the PCH: -The same header is referenced in an #include with different filename cases. -In the PCH, of course, we record only one file entry for the header file -But we cache in the PCH file the stat info for both filename cases -Then the source files are updated and the header file is updated in a way that its size and modification time are the same but its inode changes -When using the PCH: -We validate the headers, we check that header file and we create a file entry with its current inode -There's another #include with a filename with different case than the previously created file entry -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode -because of the different inodes, we think they are different files so we go ahead and include its contents. Removing the stat cache will potentially break clients that are attempting to use the stat cache as a way of avoiding having the actual input files available. If that use case is important, patches are welcome to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with literal strings, line/column computations, etc.). This fixes rdar://5502805 llvm-svn: 167172
2012-10-31 20:59:50 +00:00
def is_filesystem_case_insensitive():
handle, path = tempfile.mkstemp(prefix="case-test", dir=config.test_exec_root)
isInsensitive = os.path.exists(
os.path.join(os.path.dirname(path), os.path.basename(path).upper())
)
[PCH] Remove the stat cache from the PCH file. The stat cache became essentially useless ever since we started validating all file entries in the PCH. But the motivating reason for removing it now is that it also affected correctness in this situation: -You have a header without include guards (using "#pragma once" or #import) -When creating the PCH: -The same header is referenced in an #include with different filename cases. -In the PCH, of course, we record only one file entry for the header file -But we cache in the PCH file the stat info for both filename cases -Then the source files are updated and the header file is updated in a way that its size and modification time are the same but its inode changes -When using the PCH: -We validate the headers, we check that header file and we create a file entry with its current inode -There's another #include with a filename with different case than the previously created file entry -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode -because of the different inodes, we think they are different files so we go ahead and include its contents. Removing the stat cache will potentially break clients that are attempting to use the stat cache as a way of avoiding having the actual input files available. If that use case is important, patches are welcome to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with literal strings, line/column computations, etc.). This fixes rdar://5502805 llvm-svn: 167172
2012-10-31 20:59:50 +00:00
os.close(handle)
os.remove(path)
return isInsensitive
[PCH] Remove the stat cache from the PCH file. The stat cache became essentially useless ever since we started validating all file entries in the PCH. But the motivating reason for removing it now is that it also affected correctness in this situation: -You have a header without include guards (using "#pragma once" or #import) -When creating the PCH: -The same header is referenced in an #include with different filename cases. -In the PCH, of course, we record only one file entry for the header file -But we cache in the PCH file the stat info for both filename cases -Then the source files are updated and the header file is updated in a way that its size and modification time are the same but its inode changes -When using the PCH: -We validate the headers, we check that header file and we create a file entry with its current inode -There's another #include with a filename with different case than the previously created file entry -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode -because of the different inodes, we think they are different files so we go ahead and include its contents. Removing the stat cache will potentially break clients that are attempting to use the stat cache as a way of avoiding having the actual input files available. If that use case is important, patches are welcome to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with literal strings, line/column computations, etc.). This fixes rdar://5502805 llvm-svn: 167172
2012-10-31 20:59:50 +00:00
if is_filesystem_case_insensitive():
config.available_features.add("case-insensitive-filesystem")
# Tests that require the /dev/fd filesystem.
if os.path.exists("/dev/fd/0") and sys.platform not in ["cygwin"]:
config.available_features.add("dev-fd-fs")
# Set on native MS environment.
if re.match(r".*-(windows-msvc)$", config.target_triple):
config.available_features.add("ms-sdk")
# [PR8833] LLP64-incompatible tests
if not re.match(
r"^(aarch64|x86_64).*-(windows-msvc|windows-gnu)$", config.target_triple
):
config.available_features.add("LP64")
# Tests that are specific to the Apple Silicon macOS.
if re.match(r"^arm64(e)?-apple-(macos|darwin)", config.target_triple):
config.available_features.add("apple-silicon-mac")
# [PR18856] Depends to remove opened file. On win32, a file could be removed
# only if all handles were closed.
if platform.system() not in ["Windows"]:
config.available_features.add("can-remove-opened-file")
# Features
known_arches = ["x86_64", "mips64", "ppc64", "aarch64"]
if any(config.target_triple.startswith(x) for x in known_arches):
config.available_features.add("clang-target-64-bits")
def calculate_arch_features(arch_string):
features = []
for arch in arch_string.split():
features.append(arch.lower() + "-registered-target")
return features
llvm_config.feature_config(
[
("--assertion-mode", {"ON": "asserts"}),
("--cxxflags", {r"-D_GLIBCXX_DEBUG\b": "libstdcxx-safe-mode"}),
2020-04-13 11:53:23 -04:00
("--targets-built", calculate_arch_features),
]
)
if lit.util.which("xmllint"):
config.available_features.add("xmllint")
if config.enable_backtrace:
config.available_features.add("backtrace")
if config.enable_threads:
config.available_features.add("thread_support")
# Check if we should allow outputs to console.
run_console_tests = int(lit_config.params.get("enable_console", "0"))
if run_console_tests != 0:
config.available_features.add("console")
lit.util.usePlatformSdkOnDarwin(config, lit_config)
macOSSDKVersion = lit.util.findPlatformSdkVersionOnMacOS(config, lit_config)
if macOSSDKVersion is not None:
config.available_features.add("macos-sdk-" + str(macOSSDKVersion))
if os.path.exists("/etc/gentoo-release"):
config.available_features.add("gentoo")
if config.enable_shared:
config.available_features.add("enable_shared")
# Add a vendor-specific feature.
if config.clang_vendor_uti:
config.available_features.add("clang-vendor=" + config.clang_vendor_uti)
if config.have_llvm_driver:
config.available_features.add("llvm-driver")
# Some tests perform deep recursion, which requires a larger pthread stack size
# than the relatively low default of 192 KiB for 64-bit processes on AIX. The
# `AIXTHREAD_STK` environment variable provides a non-intrusive way to request
# a larger pthread stack size for the tests. Various applications and runtime
# libraries on AIX use a default pthread stack size of 4 MiB, so we will use
# that as a default value here.
if "AIXTHREAD_STK" in os.environ:
config.environment["AIXTHREAD_STK"] = os.environ["AIXTHREAD_STK"]
elif platform.system() == "AIX":
config.environment["AIXTHREAD_STK"] = "4194304"
# Some tools support an environment variable "OBJECT_MODE" on AIX OS, which
# controls the kind of objects they will support. If there is no "OBJECT_MODE"
# environment variable specified, the default behaviour is to support 32-bit
# objects only. In order to not affect most test cases, which expect to support
# 32-bit and 64-bit objects by default, set the environment variable
# "OBJECT_MODE" to "any" by default on AIX OS.
if "system-aix" in config.available_features:
config.substitutions.append(("llvm-nm", "env OBJECT_MODE=any llvm-nm"))
config.substitutions.append(("llvm-ar", "env OBJECT_MODE=any llvm-ar"))
config.substitutions.append(("llvm-ranlib", "env OBJECT_MODE=any llvm-ranlib"))
# It is not realistically possible to account for all options that could
# possibly be present in system and user configuration files, so disable
# default configs for the test runs.
config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"