Currently, if the user specifies the environment variable 'CLANG', tests will attempt to use the value as a path to the clang executable. Previously, lldb could also be specified via the CLANG environment variable, but this was almost certainly a bug, because that meant both clang and lldb would have the same path. This patch changes the environment variable for lldb to 'LLDB'.
|230 ms||x64 windows > Clang.ClangScanDeps::modules-inferred-explicit-build.m|
Script: -- : 'RUN: at line 1'; rm -rf C:\ws\w16c2-1\llvm-project\premerge-checks\build\tools\clang\test\ClangScanDeps\Output\modules-inferred-explicit-build.m.tmp.dir
|130 ms||x64 windows > Clang.ClangScanDeps::modules-inferred.m|
Script: -- : 'RUN: at line 1'; rm -rf C:\ws\w16c2-1\llvm-project\premerge-checks\build\tools\clang\test\ClangScanDeps\Output\modules-inferred.m.tmp.dir
We could add a lit test for the additional pass-through variables, if you think there's value in it (I don't think the other variables in the list are tested however), but I don't think we can test the lit.cfg.py change. To test that, we'd need to have a lit tests within the debuginfo-tests directory which spawns lit itself, with certain variables specified, and show that the right tools are used. I don't think this is practical. I've manually confirmed that the expected tools are used when the variables are set.
That's the overal feature I would like tested so more the lit.cfg.py side of things. If you think this is difficult to test for little value and since you have tested manually I'd say LGTM.
LGTM. Please watch the Green Dragon bot for LLDB after landing (the bot runs the debuginfo-tests + LLDB tests). I noticed some time ago that part of the debuginfo-tests there were partly running the system LLDB (and it wasn't clear to me if that was actually on purpose). So this patch might bring up some previously hidden failures.