Source location hover in CALLSTACK view shows bogus path for internal modules

[weinand]

• VSCode Version: 1.8.0 Insiders

The source path starts with the (internal) variable reference used in the debug protocol:

We should find a better path root for this.
Ideally we should use a 'magic world' that could be used in the 'Just my code' feature to filter those modules (see #16918).
But the VS Code frontend should not hardcode this.

[isidorn]

@weinand so how do you propose that this magic word is contributed to vscode? Should it come from the source response?
What should ideally appear on the hover? internal_module/module.js?

[Eli-Goldberg]

@weinand
I think this is a duplicate: #17301
This happens all the time when stepping in.
Thanks.

[weinand]

@isidorn the frontend should not have to know anything about this case. So the 'magic word' would be introduced by the backend (debug adapter) and for the debugger UI it would just appear as a regular path segment.
What is your special frontend logic around this? We should try to eliminate it completely.

[isidorn]

@weinand the frontend currently simply takes the fs path for each uri in the callstack. For internal modules this uri is fake and looks something like 'debug://internal/1056/module.js' so the fs path is 1056/module.js, namely the reference and the name.
Different internal modules need to have different uris so we decided in the past to include the reference when generting this fake uri.

Instead of using a fsPath for internal modules the frontend could use anything coming from the adapter. Should we add something to the protocol or is there already something we can use?

[roblourens]

It seems like the UI should only show module.js even if it uses the reference as a unique ID internally. Why do we need a magic word instead of only showing module.js?

[weinand]

We will continue to show only module.js in the CALLSTACK. But on hover we currently show the full path and the frontend manufactures a (fake) path by using the source ID. This is wrong.

Instead of doing this we should show something that makes clear that module.js is not a file the user will find in his workspace, but is an internal module.

If we do not want to extend the debug protocol, we could manufacture a 'better' fake path that says something like "core_modules/module.js". This would be shown on hover and we could use the core_modules in skipFiles glob patterns as well, e.g. "core_modules/**/*.js". This would be a nice consistent story.

Alternatively we could introduce some optional information attribute on the Source debug type and communicate 'internal core module' from the debug adapter to the hover. For skipFiles we would have to invent a corresponding mechanism so that the user could configure to skip internal core modules.

[isidorn]

As usual, I prefer the more pragmatic approach, the first one you proposed - manufacture a 'better' fake path.
Though I do not have strong feeling and the alternative approach would also work for me here.

[roblourens]

$/module.js, %/module.js, &/module.js? A symbol is simple but might not be clear what it means.

<node_internals>/module.js?