LSP: The Good, the Bad, and the Ugly

Re:LSP: The Good, the Bad, and the Ugly by ReleaseCandidat on Saturday September 07, 2024 @01:37AM (#41471682)

Rust-analýzer is an example of what not to do, which is reimplementing a compiler frontend. Ideálly it should be the samé as the "real" compiler is using. Of course this has it's own problems, which the Haskell LSP this post is about, shows. As compilers not written for being used "interactively".

> Any compiled language that uses LLVM gets debug symbols and rich debugging "for free".

That doesn't hold for C++ and much less for any language even "less C" than C++. Like languages using a GC, e.g. Roc https://www.roc-lang.org/

[ Parent | on HN ]

Re:LSP: The Good, the Bad, and the Ugly by forrestthewoods on Saturday September 07, 2024 @04:24AM (#41472419)

> That doesn't hold for C++

What do you mean? Why not? Clang PDBs for C++ work great. A GC isn’t particular disruptive to debug symbols afaik.

[ Parent | on HN ]

Re:LSP: The Good, the Bad, and the Ugly by ReleaseCandidat on Saturday September 07, 2024 @04:59AM (#41472581)

> What do you mean? Why not?

You need support for each language in the debugger, as symbols do not contain semantics. As users we for example know that `foo::bar` and `foo::baz` are methods of the same class `foo`, the debugger doesn't.

The problem with GCs is that pointers must contain some additional information (like an additional bit for mark and sweep), they are not "just" pointing to some memory. Without "knowing" that, the debugger cannot follow the pointer to its target. Or tricks with unboxed ints like making them 1 bit smaller and using the first 1 as a tag for "this is not a pointer, but an integer".

[ Parent | on HN ]