Open lzybkr opened 6 years ago
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."
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
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 themsvc
rust compilers:rust.natjmc
- This file could probably exclude everything instd::*
.rust.natstepfilter
- This file would have entries to exclude common helper functions or trait implementations that you typically never want to step through.