Hi.
I think having both LSP https://microsoft.github.io/language-server-protocol/ and DAP https://microsoft.github.io/debug-adapter-protocol/ implementations for Pike would be awsome, but I feel that this discussion is getting further away from it's main point. We've been talking about LSP for a little during the Conference. There is a huge interest in it and I think we should move the LSP discussion to another mailing thread to avoid mixing contexts.
Having a Pike debug adapter would also be great, but since DAP is used for estabilishing communication between IDE and the debugger, we can't move on with it until we actually have a debugger.
From what I understand the greatest challenge now would be to reach the local variables. I've heard that long time ago, the language got some optimizations that makes retrieving local variable names very challenging. Is it true? If yes, how we can jump this through?
As far as I know, information about the names and types of local variables have never been available to the runtime. Prior to 2006-02-25, the allocator for local variables was broken, causing local variables to never be reused (which could be considered to have it be less challenging then).
I would be more than happy to help crossing-out the remaining TO-DOs, if I only could get some itroduction and clues.
Sure.
Most of the code for handling local variables and their types and names is located at the end of language.yacc. Of interest are probably the functions {low_,}add_local_name() and {low_,lexical_,}islocal() in language.yacc, as well as {low_,}pop_local_variables() in pike_compiler.cmod.
The main problem in the case of debugging, is that this information is thrown away by the compiler when no longer needed.
One possible place to store the information would be in the linenumber table, but doing that would probably require adding suitable new nodes to the parse-tree (las.c), corresponding new virtual opcodes (docode.c, et al) to let the code that generates the linenumber table (peep.c) reach it. Note also that adding these extra nodes and opcodes may affect some of the optimizers.
/grubba