[wasm][debugger] Stepping into hidden function.

[ilonatommy]

How it works in Console App:

• Setting enabled breakpoints in the decorated method in VS is blocked. (DONE in Wasm)
• Stepping into the decorated method is blocked, instead debugger steps over. (DONE in Wasm)
• Using Debugger.Break() in the function result in pausing on the call of the function, no stepping in, not appearing on the call stack, no access to local variables. After resuming, the debugger steps over. (DONE in Wasm)
• Using Debugger.Break() in the function while we are stepping into results in 3 steps (in or over) on the method call. (A difference: in Blazor App it results in 2 steps on the method call).

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	ilonatommy
Assignees:	ilonatommy
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[radical]

Would you mind describing the behavior of a hidden method in a debugger? For example, can you set breakpoints in it? Can you step into it from a visible method that you were already paused at?

In the debugger.break in the hidden method case, does it not show the callstack at all? As you are already in that method, can you step through the code? or step out? Can you access locals, evaluate expressions etc?

If you are paused on a visible method, but were called from a hidden method, then does that method not show up in the callstack? If it does, then can you inspect its locals?

Feel free to point me to a doc, if any, on this.

[ilonatommy]

@radical that's a good question. For now I added a short description to this PR but I will also prepare it in a form of doc.

[ilonatommy]

@radical I prepared a document for all kind of debugger documentation and started with a draft of Hidden Attribute expected behavior #62015.