Unbound breakpoint in VSCode builtin extensions debugging - visual-studio-code

I'm new to contribute to vscode and began to improve some small bug in VSCode builtin extension, markdown-language-features.
when setting breakpoints in TypeScript file (like activeLineMarker.ts
in vscode/extensions/markdown-language-features/preview-src/ or activeLineMarker.js in out directory), the breakpoint become unbound when start debugging.
unbound breakpoint pop-up window
Is there any way or configuration to debug with step-by-step line execution with breakpoints for developping extensions?
The developping environment is just created recently with the official procedure.
Code OSS is successfully launched with Start Debugging (F5) and I can see changes when modifying sources.
The official document says;
The extension host process runs code implemented by a plugin. To debug extensions (including those packaged with VS Code) which run in the extension host process, you can use VS Code itself. Switch to the Debug viewlet, choose the Attach to Extension Host configuration, and press F5.
and doing so results in nothing happening (the debugging seems to want to start but fails, maybe time-out).
After building, there is sourcemap file like activeLineMarker.js.map in out directory.

Related

Should debugger be launched always in VScode when only running a file (not debugging) using code-runner?

In a VScode C/C++ programming setup on Windows 10 system, the "C/C++ Extension Pack", "Code Runner", "WSL" extensions are installed, which use Alpine Linux target on WSL on this PC. Alpine Linux WSL instance has the gcc dev environment, build-tools, gdb etc. installed, apart from the necessary VScode extensions needed inside WSL.
In this environment I am able to write C/C++ programs, build them, execute them, interact with them through the built-in terminal. I use the "Code Runner" "Run C/C++ file" shortcut button to build(if necessary) and run individual C/C++ program files (there is no Makefile and these are simple programs all thrown in a single folder, not in a project structure).
Recently however, I noticed that whenever I try to "Run C/C++ file", debugger is also launched and I get a screen like this (notice the 2 yellow/orange arrows indicating what I am trying to draw attention to):
I do not remember this being the case earlier, but I think this started after I tried to debug a program by setting a breakpoint, which I later cleared. I've also ensured that "Run > Remove All Breakpoints" is done, to make sure that there are absolutely no breakpoints. Therefore wondering if:
it is normal for debugger to get launched in this manner ?
if not, what exactly might have caused it ?
finally, what can I do to make sure that the debugger is not launched, when all I want to do is "Run" ?
In "Code Runner" settings file, I did not find anything that might control this behaviour, but then I am quite new to VScode so not sure if I am missing anything obvious.

Debugging new VS Code CLI flag in devcontainer

I've forked VSCode on Github to try to add a tiny little feature I think would be useful, which adds a new CLI flag to code, to be used inside the VSCode terminal (like code - for stdin). I added the code, wrote tests, and now I want to try out the feature.
I'm developing inside the built-in devcontainer, so I just launched an instance of VSCode from within VSCode, connected to the devcontainer via VNC and tried to use my flag inside the VSCode-OSS terminal. However, I get an error saying "Command is only available in WSL or inside a Visual Studio Code terminal"
According to server.cli.ts, this means that the env variables VSCODE_IPC_HOOK_CLI and VSCODE_CLIENT_COMMAND aren't set, but I don't know who should be setting them, or if I need to launch VSCode in a different way for debugging.
Has anyone using the VSCode DevContainer to write additional CLI flags and knows how to debug them?

How can I get Visual Studio Code to reset the IntelliSense engine for Rust?

I am working on two projects, one is a library, the other is a program that uses that library. When I make changes to the library the other window (the program) doesn't see these changes, so I do not get updated IntelliSense. Closing the program that uses the library and reopening it does force an update but I really prefer not having to go that far.
Answering the title directly and not the root issue...
You can reset IntelliSense and all Rust code features by running the "Rust: Restart the Rust server" command from the command palette (Ctrl+Shift+P).
Progress will be indicated in the status bar.
Still a blunt tool but it will ensure you're in a fresh state without having to restart VS Code entirely.

lisp debugging in vscode?

I'm trying to walk through the Parenscript library to see how it renders, i.e. what actually happens when you make a (ps... ) call.
Ideally, I'd use VSCode to set breakpoints and watches and step into all called functions. There doesn't seem to be any lisp debugging extension in the VSCode marketplace.
Right now, I'm loading sbcl in a terminal window in VSCode and have command-shift-A bound to Terminal: Run Selected Text In Active Terminal, so that anything I write in the editor can be executed in sbcl.
Is there a way to set up the VSCode environment so that I can have access to debugging tools like watches and step-into?

How to debug a VS Code extension when loaded from VSIX?

I have a vs code extension (currently private), and it runs fine when I run it via the VS Code debugger, (i.e., a "Launch Extension" target in my launch.json). However, when I install the extension from a vsix file, the extension never activates.
Here's what I tried:
View elements & commands show up, which implies the package.json is being read correctly.
I placed vscode.window.showInformationMessage(...) statements in my extension.js and extension.js's activate() methods. I see expected output when I launch via VS Code debugger, but not when installed via vsix file.
I changed the activation events to include "onLanguage:javascript", hoping that opening a js file would cause my extension to activate, but it didn't.
A few questions:
Any suggestions on what is going on here?
Any suggestions on how to debug this?
Any instructions on how I can attach a debugger?