Idea for a new tool

[rikki cattermole via Digitalmars-d]

On 15/10/2016 4:47 AM, Mathias Lang wrote:
> 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.

We really should move the asm block into druntime.
A single pragma could replace most of the special behavior considering 
we have CTFE.
Of course to do this properly we need to be able pass "code" as string 
to be replaced and then mixed in.

struct Asm_x86 {
     string __astParse(string text) {}
}

Asm_x86 asm;

void func() {
	asm {
		naked;
		ret;
	}
}

void func() {
	pragma(__ast_naked);
	pragma(__ast_raw, [0xC3]);
}

But I did mention this previously in a reply to another thread, there is 
still holes and needs somebody else to really go through it.