New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for "Just My Code" debugging #5763
Comments
Hi, I am a member of the Visual C++ compiler team and I use VSCode as my primary editor/debugging experience with the C++ extension. Due to the fact that our project involves a lot of |
It does not look like this is a priority issue which is a bummer because without JMC the debugging experience really sucks on those projects that are bigger than just simple "hello world" application. @WardenGnaw Is this just a matter of getting more people to vote on this issue? |
Yes, that appears. @WardenGnaw mentioned this here:
Anyway, I voted. I am curious to know what threshold must be met for this to be prioritized. To @kkutsner's point, debugging on any large project becomes clumsy rather quickly. |
It looks like we may need a lot of votes: I'm curious, this extenstion has so many user installations, but it looks like no one really uses VSCode for debugging C++ code... |
@kkutsner The vote count of the VS Code issue you referenced is not relevant, since it's managed by another team and they have a larger user base (all of VS Code instead of just C/C++ users). Our highest upvoted issue is #206 . Lots of people use our extension for debugging C++. You can use Go to Definition and set a breakpoint in the definition you want to step into to get around the issue. |
Fair point! Sorry for mentioning not quite relevant issue.
Yeah, that workaround may work sometimes, but such workaround is a productivity killer like @cdacamar mentioned already. Let's consider a test code below: I need to step through lines 46 to 52 and I want to step into line 49 for every element. In VisualStudio, I only need 4+n keyboard clicks to do that, where n is the number of elements in the vector. With "Go to Definition" workaround that is a lot more, even for such artifical code example. It is because every time I need to "Step Into" I may need to do "go to definition" then put a breakpoint (or "Run to Cursor" that sets temprorary breakpoint automatically). Also, I need to put a breakpoint after the statement before doing "Step Into" in the case something goes wrong and I did the previous breakpoint on a wrong line. After all I need to cleanup any of those breakpoints...Those extra actions take additional time and patience and that is adding up quickly. |
For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49. I agree that doing the Go to Definition and setting the breakpoint (or doing multiple step in/outs) is annoying, although with debugging our code base I haven't found it a productivity killer enough to switch to VS debugging. I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger). |
Yep, I can.
Every dev on our team has paid VS licenses. But I found that a lot of my workflows I can do using VSCode much faster: it is keyboard centric, minimalistic, mostly runs much faster than VS.... Interestingly, that Microsoft is releasing a standalone debugger application https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-using-windbg-preview that has even more features that VS can provide as a debugging experience, for example, use JS scripting to to script the debugger - mind blowing (Something similar that GDB also can do using Python for a while)! |
With smart pointers use everywhere, this is definitely a productivity killer! std::shared_ptr<Image> image = std::make_shared<Image>(10, 20);
createNewImage(Size(image->width(), image->height())); Step on line 2 will go into : With Visual Studio's |
I'm wondering if I should just switch to Visual Studio proper. Since vector-of-bool is not in charge of the extension anymore it seems its not really being developed anymore. My suspicion is also that VS Code is deprioritized to get people to move to Visual Studio. |
@maartennauta vector-of-bool worked on the CMake Tools extension -- our team is still developing that extension. This debugging issue is not related to the CMake Tools extension. Were you hitting some other issue? |
@sean-mcmanus No, my mistake probably was to assume he also worked on the cpptools extension. It seems this is the issue im also hitting (just wanting to step through my own code in the project directory when debugging C++ in VS Code, ignoring std internals and boost libraries etc) and have voted accordingly. I guess a similar request applies to "stop on exception" where I would want to only stop on all exceptions in my own code, I dont know if that is a separate issue. I have not used Just-My-Code in Visual Studio in a while so I do not know if it provides that functionality for exceptions. |
This is absolutely necessary. When debugging and stepping in/through my code I always end up stepping into a bunch of |
It has been two years since this problem was raised. Could it be solved in the near future. |
@WardenGnaw Is this feature on the debugger team backlog? Maybe those issues could be labeled with Needs more votes to help prioritize? |
Yep. This feature work is in the backlog for the debugger. Please react to the top post with a 👍 to vote on this feature. |
Now there are 58 votes. I want to know how many votes are needed to remove the problem from the backlog |
its necessary,plz add it |
This is my workaround while this feature is not enabled: GDB supports skipping files/functions and these can be predefined in e.g.
It will now skip all headers in that directory. As more functions are used, you can just add more directories to be skipped. |
Unfortunately, GDB won't stop on user code that's called from non-user code when using From piecing together info from StackOverflow, I found that this Python script works on the command line: def stop_handler(event):
if gdb.selected_frame().name().startswith("std::"):
gdb.execute("step")
gdb.events.stop.connect(stop_handler) But if I use it when debugging from VS Code, as soon as I step into any
|
How many votes do we need? This is such a productivity killer, I'm really surprised this isn't prioritized. The workaround works for simple cases, but C++ has a ton of hidden function calls everywhere so it's really annoying. |
@quyykk I don't know exactly how many votes are needed, but more than 100 would help (there are 2 other debugger features with more up votes). |
There are now 101 tickets available. Will this feature be added? |
Is there an alternative solution? |
This is a practical feature, please add it |
Voted: +1, closing: #11417 |
Debugging doesn't seem to be getting much attention.
|
I voted too. @WardenGnaw How many more votes are needed? It's currently at 122, seems pretty substantial at this point. :) |
Visual Studio debugger supports skipping source files during Step In operations by reading the non-user code filters from
*.natjmc
and*.natstepfilter
files underC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\Visualizers
folder when Just My Code is enabled in VS settings. The debugger bundled with the VSCode extension comes with a similar folder, but there is no option to turn on the Just My Code option in the extension.Related issues: #514 #3725
The text was updated successfully, but these errors were encountered: