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.

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Moderate] Please preserve the configured regex here. Leading and trailing whitespace is valid regex syntax: for example, ^my-daemon intentionally does not match my-daemon-helper, but trimming changes it to ^my-daemon. If that broadened expression has exactly one match, the code silently auto-attaches to the wrong PID instead of falling back to the picker. Trimming can still be used to detect an empty/all-whitespace value, but construct RegExp from the original string and add an edge-whitespace test.

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Moderate] Please add this property to Extension/tools/OptionsSchema.json under CppdbgAttachOptions and regenerate this file. OptionsSchema.json is the documented schema source, and generateOptionsSchema.ts replaces the complete cppdbg attach schema in package.json from it. As written, the next yarn generate-options-schema removes processFilter, including its completion, validation, and documentation. This same source/generated drift previously required #14523 to resynchronize.

[Sean McManus (sean-mcmanus)]

✨Copilot (agent135): [Minor] This newly introduced exception is user-facing through both remote-picker invocation paths, but its text is hard-coded English. Please route it through the existing vscode-nls/package.nls.json localization path (locking the processFilter identifier as appropriate) so localized installations receive a translated diagnostic.