[lldb][test] Add CMake option for extra Swift driver flags in shell tests

[speednoisemovement]

Tests that invoke swift currently fail on Windows because we're not passing -sdk. Unlike Darwin, there's no way to figure out a good value for this at runtime.

This change adds a CMake variable LLDB_SWIFT_DRIVER_EXTRA_FLAGS which takes a semicolon-separated list of arguments for the Swift driver which we pipe into the lit config.

[compnerd]

@swift-ci please test

[adrian-prantl]

Please mark all Swift-specific additions in generic code with

# BEGIN SWIFT
...
# END SWIFT

This makes resolving merge conflicts much easier.

[adrian-prantl]

(I realize this file isn't doing that, but let's add it now)

[speednoisemovement]

Done

[adrian-prantl]

Since this is meant to affect how tests are built, the more idiomatic way would be to use LLDB_TEST_USER_ARGS. The https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix bot uses that creatively to run the LLDB testsuite against different compilers and debug info options.

[speednoisemovement]

I was very excited about this, but unfortunately it seems like this only applies to API tests and the issue applies to shell tests.

[adrian-prantl]

I'm also generally confused about the exact use-case for this. When talking to @compnerd today, I came away with the impression that on Windows -sdk points to the Swift toolchain. When running the tests on a just-built LLDB, the Swift toolchain should be in the exact same directory as LLDB, no?

[compnerd]

I'm also generally confused about the exact use-case for this. When talking to @compnerd today, I came away with the impression that on Windows -sdk points to the Swift toolchain. When running the tests on a just-built LLDB, the Swift toolchain should be in the exact same directory as LLDB, no?

No, the -sdk doesn't point to the toolchain, it points to the "SDK" - the standard library, core libraries, API notes, etc. On Windows, the SDK is not in the same location as the toolchain, it is spilt.

[adrian-prantl]

No, the -sdk doesn't point to the toolchain, it points to the "SDK" - the standard library, core libraries, API notes, etc. On Windows, the SDK is not in the same location as the toolchain, it is spilt

Maybe the Windows build works differently, but on other platforms the standard library is built as a dependency of LLDB and its location is the Swift compiler's build dir (which should be LLDB's build dir in a unified build) + /lib/swift/$platform. Is this not how it works on Windows?

[compnerd]

No, the -sdk doesn't point to the toolchain, it points to the "SDK" - the standard library, core libraries, API notes, etc. On Windows, the SDK is not in the same location as the toolchain, it is spilt

Maybe the Windows build works differently, but on other platforms the standard library is built as a dependency of LLDB and its location is the Swift compiler's build dir (which should be LLDB's build dir in a unified build) + /lib/swift/$platform. Is this not how it works on Windows?

Windows has generally been the platform that has been pushing the build to a more structured place. The Windows build does not build the standard library as part of the toolchain. The distributed runtime cannot be tested with a version of the runtime that can be built into the same build tree as that build cannot be built in a similar configuration.