Skip to content
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

Provide natstepfilter and/or natjmc files for debugging with Visual Studio #50005

Open
lzybkr opened this issue Apr 16, 2018 · 2 comments
Open
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@lzybkr
Copy link
Contributor

lzybkr commented Apr 16, 2018

Visual Studio has support for specifying functions to step over unconditionally, or to step over if debugging "just my code". See the documentation here.

I'm investigating if these files can be embedded in the pdb (like a natvis file with the /NATVIS linker flag) - but I think it would still be useful to simply include two files with the msvc rust compilers:

  • rust.natjmc - This file could probably exclude everything in std::*.
  • rust.natstepfilter - This file would have entries to exclude common helper functions or trait implementations that you typically never want to step through.
@XAMPPRocky XAMPPRocky added O-windows Operating system: Windows C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-windows-msvc Toolchain: MSVC, Operating system: Windows A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) labels Aug 27, 2018
@pnkfelix
Copy link
Member

pnkfelix commented Sep 19, 2022

Visiting for wg-debugging triage.

I am trying to figure out whether the nature of the files being described here are things that one might expect end-users to customize (so that they can pick and choose which crates count as "their code"), or if these files are things that we can only reasonably expect rustc (perhaps with some help from cargo) to generate.

In particular, @wesleywiser notes "Given the proliferation of 3rd party dependencies beyond the standard library, I don't know that doing something that only accounts for libstd will improve the UX significantly."

@wesleywiser
Copy link
Member

Reposting my comment during the triage discussion:

I think there's a more complex feature here where we decide what is "your code" and "your dependencies" code when compiling a !rlib and generate a complete file that also filters out code from your dependencies, not just the standard library.

We need some kind of concept of "your code" in rustc. Right now there's only "the current crate" and "other crates". If you're in a workspace though, some of those other crates are also "your code".
We might also want this for diagnostic reasons. We could then potentially suggest changes to code in other crates in the current workspace if that gives a better solution to the compiler error we've generated.

@pnkfelix said:

I see. So yeah, we might want cargo to feed a description of that boundary into rustc itself when it invokes it.

it might warrant an RFC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants