Removing libdparse dependency from DLS

[Mathias Lang]

On Thursday, 20 February 2020 at 18:58:12 UTC, Cristian Creteanu 
wrote:
>
> The cleanest way to solve this would be to replace libdparse 
> with dmd in dcd and dscanner, as well. Would this be a good 
> idea? Should I approach this differently?

Not familiar with DLS / DCD source code, but quite familiar with 
DMD.
Things have definitely gotten better since the first time I 
attempted this, but it's definitely non-trivial, depending on 
what you are trying to do.

I can confirm that the global state and the memory allocation are 
still issues.
I don't know about standard output, has some PRs have been made 
to use a delegate (https://github.com/dlang/dmd/pull/10072 and 
https://github.com/dlang/dmd/pull/10711), so things might be 
better on that front.

Two other large issues:
- DMD is not built to be able to handle edit cycles, only 
complete & valid source files.
   When working on an IDE, you'll have to deal with incomplete 
source code (e.g. typing `format("`) and you want to be able to 
provide completion for parameter, return value, overload sets, 
etc... Doing so would require large refactorings in DMD which are 
likely to raise some eyebrows.
- DMD semantic analysis is destructive. Many things are rewritten 
and some links are lost, and the rewrite might not be valid D 
code. One example, any `alias this` is just rewritten as a direct 
call, but bypassing visibility checks on the target, so writing 
the same code would produce an error.
  Some expressions are rewritten as ComaExpression and use the 
return of that expression. This is also very evident with 
`alias`, as they are resolved as early as possible. There are 
quite a few places in DMD that work around this issue (e.g. 
`immutable(char)[]` is special-cased to always show as `string` 
in error message, and the POSIX C++ mangler uses a mix of pre and 
post-semantic AST to work around that issue as soon as templates 
are involved).