• kinke (2/2) Apr 18 2018 I added my workflow to
• Radu (23/25) Apr 24 2018 Experiencing lately some of what this means I realized that there
• kinke (18/20) Apr 25 2018 Syncing druntime and Phobos is mostly easy-peasy, except

kinke <noone nowhere.com> writes:

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.

Radu <void null.pt> writes:

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.

kinke <kinke libero.it> writes:

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.