On Friday, 14 October 2016 at 13:21:18 UTC, Andrei Alexandrescu
On 10/14/2016 09:20 AM, rikki cattermole wrote:
On 15/10/2016 2:17 AM, Andrei Alexandrescu wrote:
On 10/14/2016 09:15 AM, rikki cattermole wrote:
On 15/10/2016 2:13 AM, Andrei Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei
As asked for time and time again, this shouldn't be an
handling it but dmd-fe should.
What is dmd-fe?
dmd front end
Yah, making the front end a library would probably be a good
way to create such a tool. -- Andrei
And to enable the creation of many others.
I've looked into pluging DMD-FE inside a Vibe.d server a while
ago, in order to be able to link usages to declarations (and the
other way around) using a Github API.
There are a couple of things that prevented any usage of the FE
as a library:
- The frontend uses loads of globals and static - not only does
it makes for an horrible library interface, but it makes it so
that you cannot just discard the result of a semantic analysis
and start over.
- DMD currently disables the GC. Enabling it causes random errors
- All files in DMD should have to be moved to match their package
definition ( explanation in
https://issues.dlang.org/show_bug.cgi?id=16071 , there was also a
thread on this topic a couple of weeks ago).
- The frontend depends on the backend when inline ASM is involved
(and if you want to parse druntime's modules...). You can make
this a soft dependency in some cases, but then the frontend just
won't see your `ret` for example, so your flow control should not
depend on your inline ASM.
- There were also random errors, most likely due to memory
corruption, caused when compiling the frontend in (without any
actual usage). For example, a global AA in Vibe.d got it's length
While those issues are fixable with some effort, there doesn't
seem to be any particular interest upstream towards making this
work. If it is indeed a desirable direction, then maybe we could
head to dmd-internals about what needs to be done, and how.