LDC - DMD sync strategy

[Kai Nacke]

Hi Yuriy!

On Monday, 24 March 2014 at 09:51:34 UTC, Yuriy wrote:
> Hello, I've been looking at LDC sources and it seems a bit 
> weird to me, that DMD is not used as a submodule. If LDC aims 
> to provide LLVM generation, using original DMD as a frontend, 
> it will get hard to maintain merges from original DMD over 
> time. And it seems to me, that it is already, as DMD is not 
> up-to-date there. E.g. while DMD factored out toIR and toElem 
> to visitors, LDC still uses old design.
>
> If i'm right and such problem exists, what do you think of the 
> following plan to fix this:
> 1. Create a DMD fork. Create an ldc-dmd branch in it, and 
> replace it's contents with current DMD state in LDC.
> 2. Start using DMD fork with it's ldc-branch in LDC repo as a 
> submodule.
> 3. Gradually refactor LDC and ldc-dmd branch with the goal to 
> completely eliminate differences between ldc-dmd branch and DMD 
> fork master.
> 4. Repeat step 3, until complete =)
> 5. Switch submodule to DMD fork master, and close dmd-ldc 
> branch.

Well, merging the DMD frontend is not the problem. The 
merge-2.064 and merge-2.065 contains the merge of the last 2 DMD 
releases. (The latter one contains the refactoring using visitor 
pattern.)
In fact, I have a MSBUILD script to do the merge - I only have to 
resolve conflicts, which is usually simple.

The real problem is that a change in the frontend must be handled 
in the glue layer between frontend AST and LLVM IR. This must 
always be done manually.

E.g.: there is only 1 test failure left in the merge-2.064 
branch: a missing symbol in std.uni unittest. The merge-2.065 
branch has some more problems in phobos unit tests - because I 
did not fixed the changes.

Any help here is appreciated.

Regards,
Kai