Process exited with status -1 when debugging tests via codlens

I'm trying to get the debugger working for unit tests running via code lens.

I found this project which appears to be integrated with rust-analyzer now. So as far as I have gotten is:

1. installed rust-analyzer
2. installed CodeLLDB
3. place a breakpoint in VSCode
4. click the Debug link above the #[test] annotation in my Rust code

expected behavior:

Test runs and breaks to the debugger at the given point

actual behavior:

VSCode shows an alert with the message: process exited with status -1 and links to the launch.json.

So I guess this is a problem of the launch configuration?

Currently this is what I have (it was created automatically by VSCode and I haven't touched it):

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "pwa-chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:8080",
            "webRoot": "${workspaceFolder}"
        },
    ]
}

Obviously this is a chrome launch task, so it won't work. But I could not find documentation on what the correct configuration should be. Does that doc exist anywhere?

Also in case it's important, the project is a rust workspace, and it also contains a VSCode extension in the top level directory, so maybe that is why VSCode thinks it's a js/web project?

The crate where the test is written is a library.

edit:

So actually it looks like the correct debug launch config is being generated somewhere. If I look at the Debug channel output in VSCode I see the following:

Launching debug configuration:
{
  "type": "lldb",
  "request": "launch",
  "name": "test grammar::expression::prefix::test_parse_prefix_func3",
  "program": "${workspaceFolder}/target/debug/deps/lib_foo-ce69ba32a3ee2c6a",
  "args": [
    "grammar::expression::prefix::test_parse_prefix_func3",
    "--exact",
    "--nocapture"
  ],
  "cwd": "${workspaceFolder}",
  "sourceMap": {},
  "sourceLanguages": [
    "rust"
  ],
  "env": {
    "RUST_BACKTRACE": "short",
    "ELECTRON_RUN_AS_NODE": "1",
    "USER": "spencerkohan",
    "__CFBundleIdentifier": "com.visualstudio.code.oss",
    "COMMAND_MODE": "unix2003",
    "LOGNAME": "spencerkohan",
    "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/opt/homebrew/bin:/opt/homebrew/opt:/Users/spencerkohan/.cargo/bin",
    "SSH_AUTH_SOCK": "/private/tmp/com.apple.launchd.4fQi9t2b3I/Listeners",
    "SHELL": "/bin/zsh",
    "HOME": "/Users/spencerkohan",
    "__CF_USER_TEXT_ENCODING": "0x1F5:0x0:0x0",
    "TMPDIR": "/var/folders/wz/8f56zmfn6c9616kmwrk0vv400000gn/T/",
    "XPC_SERVICE_NAME": "application.com.visualstudio.code.oss.6324481.6324486",
    "XPC_FLAGS": "0x0",
    "ORIGINAL_XDG_CURRENT_DESKTOP": "undefined",
    "VSCODE_NLS_CONFIG": "{\"locale\":\"en-us\",\"availableLanguages\":{},\"_languagePackSupport\":true}",
    "VSCODE_IPC_HOOK": "/Users/spencerkohan/Library/Application Support/VSCodium/1.53.2-main.sock",
    "VSCODE_PID": "74600",
    "SHLVL": "0",
    "PWD": "/",
    "OLDPWD": "/",
    "_": "/Applications/VSCodium.app/Contents/MacOS/Electron",
    "VSCODE_AMD_ENTRYPOINT": "vs/workbench/services/extensions/node/extensionHostProcess",
    "VSCODE_PIPE_LOGGING": "true",
    "VSCODE_VERBOSE_LOGGING": "true",
    "VSCODE_LOG_NATIVE": "true",
    "VSCODE_IPC_HOOK_EXTHOST": "/var/folders/wz/8f56zmfn6c9616kmwrk0vv400000gn/T/vscode-ipc-25ff31bf-8f67-4a88-8326-97d5c8f0b3e1.sock",
    "VSCODE_HANDLES_UNCAUGHT_ERRORS": "true",
    "VSCODE_LOG_STACK": "true",
    "APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL": "true"
  }
}

Which seems reasonable. Is it possible this has something to do with the fact that I'm on an M1 Mac?

Is there any way to get more details on exactly which process is failing?

More info on my setup here:

system: MacBook Air M1 202 / macOS 11.0.1
vscodium details:
Version: 1.53.2
Commit: 622cb03f7e070a9670c94bae1a45d78d7181fbd4
Date: 2021-02-12T00:30:20.237Z (6 days ago)
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Darwin x64 20.1.0
rust-analyzer version: 0.2.481

Start with the Debug channel output and the generated LLDB launch configuration shown in the issue, then reproduce debugging a Rust library test from the Code Lens on the reported M1 Mac setup. Trace which process returns status -1 and compare the rust-analyzer, VSCode/VSCodium, and CodeLLDB interaction. Done means the failing process and cause are identified, with a reproducible fix or documented limitation.