DMD as a library - recap, next steps

[evilrat]

On Tuesday, 16 June 2020 at 04:13:10 UTC, RazvanN wrote:
> A few years ago, I worked on a project to refactor the dmd 
> codebase so that it becomes easier to be used as a library. 
> This has the advantage that tools that use dmd-as-a-lib will 
> rely on the latest working compiler.

Nice progress so far, but I would also like to note that there 
was some annoying change some time last winter that puts whole 
compiler configuration in a private functions.

I know this is probably better addressed in dub instead, but it 
is just way less maintained than dmd.

Simply put, this dmd-as-a-library can be incredibly useful in 
doing custom code transformation step by serving as dmd proxy, 
however dub probing is too strict and relies on CTFE 
introspection results in std output, and that changes I mentioned 
currently forces one to copy-paste ~500 lines of code for option 
parsing and configuration, so it can be recognized by dub as 
actual compiler.
(last time I checked it in March)

> On this point, me and Edi Staniloiu have been working with a 
> bachelor student to see what interface is required to be able 
> to use dmd-as-a-lib in tools in the ecosystem (like DCD).
> - Add some visitors that make it easy for 3rd party tools to 
> use compiler features.
>

This would be awesome, it can even end the "IDE support sucks" 
complains.
If dmd will be able to do recompile in memory on code update to 
provide compilation database updates in under 500ms it will be 
usable enough to use in LSP's and other productivity tooling 
while actually supporting every language feature including 
template instance body inspection and UFCS.