Fix --prof-startup never being able to profile renderer/extension host

[winstliu]

--remote-debugging-port is documented as only accepting a port.
Similarly, --inspect-brk-extensions runs through parseDebugParams, which directly tries to convert the argument into a number.

So, remove the host from both arguments.

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@bpasero

Matched files:

• src/vs/code/node/cli.ts

[Copilot]

Pull request overview

Fixes --prof-startup startup profiling by ensuring Electron/Node debug-related CLI switches are passed in the format they actually accept, so renderer and extension host profiling can attach successfully.

Changes:

• Pass --remote-debugging-port as a port-only value (no host).
• Pass --inspect-brk-extensions as a port-only value (no host), matching parseDebugParams behavior.

[deepak1556]

Thanks! can you remove profileHost on inspect-brk it is also redundant https://github.com/nodejs/node/blob/4f08c6478d6ecd073c03536b8a6c473232e16c37/src/node_options.h#L90

Also for --remote-debugging-port I believe we also need remote-allow-origins since a while back.

cc @connor4312 host parameters were added in #209142

[winstliu]

Yep, let me get to that on Wednesday :)

[winstliu]

Also for --remote-debugging-port I believe we also need remote-allow-origins since a while back.

I'm not sure this is needed. It's only checked if an Origin header is supplied, which wouldn't be the case for --prof-startup since I'd only expect browsers to send an Origin header when connecting, right? Versus what VS Code is doing with v8-inspect-profiler.

[deepak1556]

Thanks for checking, you are right it shouldn't affect non-browser clients.