Xcode 13.3 has broken debugging testing in the VSCode swift extension

Development LLDB
1

With the release of Xcode 13.3 debugging tests in the Visual Studio Code swift extension has broken. Unfortunately VSCode is still reliant on Xcode to provide a version of xctest on macOS. Debugging tests involves sending xctest to lldb. Prior to the release of 13.3 this worked fine. Now I get the error

error: more than one platform supports this executable (host, remote-macosx), 
specify an architecture to disambiguate

I know on the command line I can get around this by adding --arch parameter setting the architecture. I don't have control over the starting of lldb that is done by another extension CodeLLDB. Is there other way to specify the architecture eg via environment variable?

2

Can you explain the workflow that you are using in more detail? How is VSCode invoking LLDB?

3

Hi Adrian,

As I said I am using the CodeLLDB extension to invoke lldb. I don't have control over how it is invoked. I create a launch configuration like below

{
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "MyProject Tests",
            "program": "/Applications/Xcode.app/Contents/Developer/usr/bin/xctest",
            "args": [".build/debug/myProjectPackageTests.xctest"],
            "env": {},
            "cwd": "${workspaceFolder:myProject}",
        }
    ]
}

CodeLLDB then uses this information to setup a debugging session.

I was wondering what has changed to cause this issue? Is it because xctest now contains both x86_64 and arm64e executables?

4

I've narrowed this down to a change in lldb between Swift 5.5 and 5.6. In Swift 5.5 if I supplied a universal binary that contained both arm64e and x86_64 executables lldb would automatically choose the correct executables to run based on the system it is running on. In Swift 5.6 this is no longer the case and you are required to specify the architecture. What was the reason for this change?

5

Can I recommend filing a bugs.swift.org report as well? It's useful to track this kind of issue.

6