I added my workflow to https://wiki.dlang.org/LDC_contributor's_guide#Merging_a_new_DMD_release. Let me know if there are better ways to tackle it, as probably everyone doing it in the past came up with a scheme of his own.

On Wednesday, 18 April 2018 at 18:18:07 UTC, kinke wrote:
> I added my workflow to https://wiki.dlang.org/LDC_contributor's_guide#Merging_a_new_DMD_release. Let me know if there are better ways to tackle it, as probably everyone doing it in the past came up with a scheme of his own.

Experiencing lately some of what this means I realized that there is way to much manual work involved in syncing LDC with mainline. Worse, the merging is done in big chunks and usually requires a expertise on compiler (dmd/ldc), runtime, phobos.

I was thinking that a more automated process could make most of that sync a simpler task, at least for phobos and druntime.

I envision something like:

- Create merge branch with in sync with mainline

- Each time a PR is merged in mainline, create a merge PR on LDC side, try to auto-merge it.

- If merge fails notify code owners for file/section (similar to code owners in mainline) and the PR author.

- Manually fix merge issues, repeat merge step

- If merge succeeds, run auto-tester, if tester fails notify owners/author

- Fix issues with tests, repeat auto-test

- If not issues with test, merge the merge PR

- Annotate files/modules that need special attention and should not be auto-merged

- Repeat for next mainline release

Another bonus is that any issue is know earlier on, no need to wait for next release to realize you missed something for LDC.

Syncing druntime and Phobos is mostly easy-peasy, except sometimes for some modules with heavy LDC specifics such as std.math and rt.sections.

The bigger problem with auto-sync is that druntime/Phobos and the compiler need to be kept in sync, i.e., some druntime patches only work after compiler modifications, or (more seldomly) the other way around.
That's why we're doing these v2.x => v2.(x+1) steps, that keeps the maintenance burden at acceptable levels without having to keep up promptly with DMD's pace.

As to merging front-end changes automatically, I think that's pretty utopic. It's just one piece of the compiler (with a number of LDC specifics and so much potential for merge conflicts in refactorings), and a feature such as minimal druntime support is something which basically needs to be re-implemented by LDC from scratch, as it's almost glue-layer exclusive.

> Another bonus is that any issue is know earlier on, no need to wait for next release to realize you missed something for LDC.

I'm afraid DMD pulls would get stalled even more if they had to additionally worry about LDC.