Add processFilter for remote attach process selection

[afreof]

Problem

When attaching to a process on a remote target (useExtendedRemote or pipeTransport), the process to attach to always has to be picked manually from the full process list on every debug session, even though a generated launch.json already knows which executable it targets. The PID can't be hard-coded because it changes on every restart/boot, and picking the wrong entry silently produces a session with mismatched symbols and source mappings.

This mirrors the existing program-based auto-selection already used for local attach (findProcessByProgramName), which does not apply to remote attach because the remote process list comes from a different source (RemoteAttachPicker) and its label/detail shapes differ per transport.

Solution

Adds an optional processFilter (regular expression) to the cppdbg attach configuration:

• Matched against label, description, and detail of each remote process entry (the exact fields differ by transport: useExtendedRemote puts the user + full command line in label; pipeTransport puts the process name in label and the command line in detail).
• Exactly one match → attach to it directly, no picker.
• Multiple matches → show the picker, pre-filtered to only the matching entries.
• No match → fall back to the full picker, unchanged from today.
• An invalid regular expression throws a clear error instead of silently matching nothing.

Scope: this only affects remote attach (pipeTransport / useExtendedRemote). Local attach is unaffected by this PR.

Example launch.json:

{
    "name": "attach my-daemon",
    "type": "cppdbg",
    "request": "attach",
    "program": "/path/on/build/host/to/unstripped/my-daemon",
    "MIMode": "gdb",
    "miDebuggerPath": "/path/to/aarch64-poky-linux-gdb",
    "miDebuggerServerAddress": "192.168.7.2:1234",
    "useExtendedRemote": true,
    "processFilter": "/usr/bin/my-daemon"
}

Closes #14682.

Open question for maintainers

Should processFilter also apply to local attach, in addition to (or instead of) the existing program-based basename matching? Since program is a required field for cppdbg attach, both would typically be present locally at the same time, so the semantics need a decision — I'd lean towards intersecting with the program match (never letting processFilter alone select a process unrelated to program) rather than giving it precedence, but wanted to keep this PR scoped to the originally requested remote-only case and get feedback before extending it.

Testing

• Added unit tests for the matching helper (empty/non-string filter, label/description/detail matching, multiple matches, invalid regex) — see Extension/test/unit/processFilter.test.ts.
• Full existing unit test suite passes (208 passing).
• Manually verified against a real gdbserver --multi target with useExtendedRemote: true:
  • unique processFilter match attaches directly without showing the picker
  • a filter matching multiple processes shows the picker pre-filtered to those entries
  • a filter matching nothing falls back to the full, unfiltered picker (existing behavior)

[afreof]

@microsoft-github-policy-service agree company="Siemens AG"

[Copilot]

Pull request overview

Adds regex-based remote process selection for cppdbg attach configurations.

Changes:

• Filters remote process candidates by label, description, or detail.
• Automatically attaches on one match and narrows the picker on multiple matches.
• Adds configuration schema, documentation, and unit tests.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Extension/src/Debugger/processFilter.ts	Implements process filtering and regex validation.
Extension/src/Debugger/attachToProcess.ts	Applies filtering during remote attach.
Extension/test/unit/processFilter.test.ts	Tests matching and validation behavior.
Extension/package.json	Defines the processFilter configuration property.
Extension/package.nls.json	Documents the new property.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Moderate] Two correctness findings and one localization finding are noted inline.

[Copilot]

🟡 Changes recommended

Missing process fields are treated as empty strings, allowing some filters to select processes they do not actually match.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 2
• Review effort level: Balanced

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Minor] The two Copilot findings are fixed; one focused regression-test gap remains inline.

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Minor] Please add a regression case for the absent-field behavior fixed in this revision. With this fixture, filterProcessItems(processes, '^$') should return no entries because the missing detail fields are not empty strings; an explicitly empty field can be included to preserve that distinction. This test would fail the prior ?? "" implementation and directly protect the fix.