Annotation to make a function "opaque" during debugging

[kyouko-taiga]

I am a fan of step-debugging, which is the tool I use the most to develop/debug hc's sources. One consistent pain point in this code base is that the "step into" feature enters functions into which I actually never want to step. For example, consider the following statement:

appendExtensions(declaredIn: AnyScopeID(m), extending: subject, to: &partialResult)

If I use "step into" when my debugger reaches this statement, I will first jump into the constructor of AnyScopeID. But I never care about this constructor. Instead, I'd like to directly jump into appendExtensions.

We could solve this issue if I had a way to annotate AnyScopeID's constructor as a function into which the debugger isn't supposed to enter. This annotation would be a tool we can use during an interactive debugging session and remove once we're done.

[dabrahams]

I don't think this should be in the language proper. I also don't think I want to change the source to do this, and often as a developer you won't control the source you'd want to avoid stepping into; e.g. it might be the standard library. Being able to avoid stepping into certain things is useful, and a good debugging tool would be able to maintain an external record of these things. I'd be surprised if LLDB doesn't have a feature like this, actually.

[tothambrus11]

I saw some existing features in JetBrains IDEs for this in python/javascript: the Smart Step Into action allows the developer to specify which function to enter when there is more than one.

The default C/C++ step into functionality in CLion is to skip any specified functions, and we can 'force step into' functions if we want to step into something normally skipped.

I am uncertain how accurate this glob pattern can be for function names, as the same names might appear in different namespaces - though it might get the job done in practice, it's just a matter of saving 2 seconds or not in some edge cases.

I think specifying the debugger's special behaviour in source code would cause more confusion than it could help if this skipping feature is enabled by default, as people use their debugger as a source of truth for how their program or library behaves, and if there are some functions magically excluded, developers might get a false sense of evaluation order / semantics, though experienced users would quickly realize what's going on.

If the behaviour is opt-in for developers using a particular library, they could review the list of ignored functions that were annotated (or just the fact that magic is going on), which would hopefully eliminate most confusion. In-source annotations could be more convenient than needing to specify all "simple" functions one by one on the user side, and less prone to becoming obsolete than the library maintainers having to create a library-level config file of skipped functions. This comes with a bit of clutter in the source though, and we might want to save that space for something more important.

Do you think there are any useful patterns that a debugger could reliably identify to ignore?