https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei

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 external tool handling it but dmd-fe should.
Sadly this will require some significant work.

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 external tool
> handling it but dmd-fe should.

What is dmd-fe?

> Sadly this will require some significant work.

s/Sadly/Fortunately because now we have smart graduate students looking for cool projects/


Andrei

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 external tool
>> handling it but dmd-fe should.
>
> What is dmd-fe?

dmd front end

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 external tool
>>> 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

On 15/10/2016 2:21 AM, Andrei Alexandrescu wrote:
> 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 external tool
>>>> 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

It is to my understanding that to implement such a thing would require a significant refactor + additions. There is a reason why it hasn't been hacked in yet even with such high demand.

But I'll leave it to somebody more knowledgeable about it to actually say what has to be done.

On Friday, 14 October 2016 at 13:13:16 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei

Reminds me of Lisp, where they also have code generation wrapped in code generation wrapped in ... here is an example: http://stackoverflow.com/q/16579844/2361979

Lispers have a REPL and can expand interactively and specifically, though.

I guess the most awesome D use case would be inside an IDE. Click on a template/mixin call to expand exactly that one. An IDE would have access to all build and link parameters, which naturally influence this.

For example, click on "foo.find(bar)" and it opens a new buffer/tab/window, where the correct variant of find is instantiated according to foo and bar.

Click on "mixin Foo;" and it inlines the instantiated code.

On Fri, 14 Oct 2016 09:13:16 -0400, Andrei Alexandrescu wrote:

> https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei

For the love of potatoes, please take a few seconds to tell us the gist of it here.

The requested tool is a preprocessor, of sorts: evaluate version statements and mixins and expand templates. That lets you see what's going on in your code a bit better in the case of extensive metaprogramming.

On Friday, 14 October 2016 at 13:53:15 UTC, qznc wrote:
> I guess the most awesome D use case would be inside an IDE. Click on a template/mixin call to expand exactly that one. An IDE would have access to all build and link parameters, which naturally influence this.
>
> For example, click on "foo.find(bar)" and it opens a new buffer/tab/window, where the correct variant of find is instantiated according to foo and bar.
>
> Click on "mixin Foo;" and it inlines the instantiated code.

I agree, I've been dreaming about this for a long time aswell.

On Friday, 14 October 2016 at 13:21:18 UTC, Andrei Alexandrescu wrote:
> 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 external tool
>>>> 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 during semantic.

- 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 reset.


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.