C++ -> D

[MartinNowak]

• remove all C++ sources that were replaced by D sources
• adjust idgen to generate id.d instead of id.c
• remove magicport
• change dmd target in makefiles to build from D sources

[MartinNowak]

Mmh, git rename detection doesn't seem to work. This means the change will make invalidate every PR and make it hard to track history. Any ideas how to help git to detect the renames?

[9rnsr]

Git does not have true file rename track system. Whether a file rename happens or not, is detected by the concordance rate of contents. And C++ to D conversion modifies almost 100% of source code lines in a file.

[MartinNowak]

And C++ to D conversion modifies almost 100% of source code lines in a file.

I think git's threshold if 50% by default. So maybe if we omit the indentation changes in the first commit, more files can be detected as renames.

[MartinNowak]

Let's try to find out, why the objc test fails @yebblies.

[dnadlinger]

The earlier LDC error message you posted indicates an ABI mismatch of some sorts in the compiler, which might or might not be related.

[MartinNowak]

The earlier LDC error message you posted indicates an ABI mismatch of some sorts in the compiler, which might or might not be related.

That was for objc.di and objc_stub.d. This one is just for objc.d and it's also in a different method.

[WalterBright]

I suggest abandoning using git rename. Just add these files as new files, and remove the .c ones. The only thing that would make me reluctant to remove the .c ones is if it will affect the diffs of the unmerged PRs. Having the diffs break would make it more difficult to redo them.

[WalterBright]

Auto-merge toggled on.

Off to Scotland! https://www.youtube.com/watch?feature=player_detailpage&v=qxDJMn-534Y#t=104

[MartinNowak]

Apparently we need to split std.algorithm unittest building, see dlang/phobos#3553.

[yebblies]

Auto-merge toggled off

[yebblies]

Yeah, I forgot about the win64 failure.

The only thing that would make me reluctant to remove the .c ones is if it will affect the diffs of the unmerged PRs. Having the diffs break would make it more difficult to redo them.

Having git pick them up as renames is not going to help much anyway. Pull requests can be ported over by rebasing on top of the last commit before this is merged and running the converter to get the D version of the patch.

[MartinNowak]

Pull requests can be ported over by rebasing on top of the last commit before this is merged and running the converter to get the D version of the patch.

Can you please write a more detailed explanation of that in the wiki and/or newsgroup.

[MartinNowak]

Auto-merge toggled on

[MartinNowak]

Or did you turn off the auto-merge on purpose @yebblies?

[yebblies]

Auto-merge toggled off

[yebblies]

Sorry, I did just turn it off because of the failure, but I think this still needs a couple of changes to make updating pull requests easier.

[9rnsr]

Ideally, each ddmd release will be built by the previous official release. The only reason for 2.067 is a temporary thing to accommodate LDC/GDC building ddmd.

Hmm, OK. I think you meant the bootstrap process should succeed in each dmd commits.
So one more question: If a new merged dmd PR breaks the bootstrap process by accident, how that would be detected? For example, after the ddmd started, if I commit a problematic D code that hits issue 14815 into dmd repo, the generated ddmd.exe will be broken silently. Do we already have fail-safe method to avoid such the problem?

[WalterBright]

how that would be detected?

That's what the test suite is for. I know it is inadequate, but it's the only answer.

14815 can also be avoided by not having static arrays of objects with destructors, and I don't think the dmd source code has any of that anyway.

[ibuclaw]

Do we already have fail-safe method to avoid such the problem?

Has the autotester been updated to do three-stage builds?

The complete failsafe should be:

1. Host ddmd builds the PR and runs testsuite + unittests (this is already done).
2. PR ddmd builds itself and runs the testsuite + unittests
3. PR ddmd number 2 builds itself and we check md5sums match the previous bootstrap.

I can't think of any other way to prevent silent corruption.

[WalterBright]

@ibuclaw is right. (I misunderstood.) I do that with DMC++. It's effective.

[9rnsr]

That's what the test suite is for.

Yet not known bugs cannot be detected by the test suite.

14815 can also be avoided by not having static arrays of objects with destructors,

It's workaround. While using 2.067 as the host compiler, all of dmd committers should know that and reject all PRs that will add it.

I don't think the dmd source code has any of that anyway.

I'm talking about the situations after the ddmd will be actually started.

[9rnsr]

Has the autotester been updated to do three-stage builds?
The complete failsafe should be:

@ibuclaw Also to me, the mechanically testable suite is enough. Is the process already in makefile? (I couldn't find it in win32.mak) I think we should develop and ready it before ddmd started.

[9rnsr]

IMHO, we core dmd committers should learn additional prior knowledge to start ddmd development. Does someone write text about that? If exists, I'd like to read it.

My most big worry is that, the current dmd is not yet stable enough to me. Small but not less major/critical bugs exist (let's search bugzilla issues). Big language design/behavior issues (e.g. issue 313/314) is not yet fixed. When we'll start to rely on current D(dmd) behavior, we should also consider the yet not fixed bugs and problematic behaviors in current D. I'm afraid that it would become additional maintenance cost for our core dmd developers.

I'm interest with the dmd development by using D.
But I'm yet not sure it will be actual benefit in this time.

[WalterBright]

@9rnsr we cannot recommend that other people use D if we are afraid to use it for the compiler.

[9rnsr]

@WalterBright Indeed... OK, I accept the changes toward ddmd. So, my last concern is the mechanical check system suggested by Iain. I'll add a trello card for that.

[WalterBright]

Thank you, @9rnsr

[9rnsr]

I'll add a trello card for that.

Done: https://trello.com/c/4tefvo4i/51-add-three-stage-builds-for-ddmd

[WalterBright]

@yebblies ping?

[yebblies]

Now to automate the switch step.

[WalterBright]

This used to pass all the tests, now no longer. What's the current state of things? Ping @yebblies ping @MartinNowak

[MartinNowak]

Daniel did most of my changes and more in separate PRs, so this won't merge any longer.
Apparently he's working on some script to automate the translation now.

[yebblies]

I guess it can be done with 1) run conversion, 2) apply diff to makefiles?

Can we cut down on the diff size and just change the rule for dmd.exe, then clean up after the switch?

[WalterBright]

Whatever it takes to make this happen. It's been 5 days now :-(

[yebblies]

Haven't forgotten, just busy with real world work.

[WalterBright]

@yebblies I understand that real world work can interfere. Should @MartinNowak simply rebase this so it works again and move forward with that?

[yebblies]

@WalterBright We've already been over why this branch is not enough.

[MartinNowak]

@yebblies what's left to do? Can we help somehow?

[yebblies]

@MartinNowak Can you see anything missing from this commit? If not I'll turn it into a pull request.

yebblies@588ecd7

[MartinNowak]

@MartinNowak Can you see anything missing from this commit? If not I'll turn it into a pull request.

Yes, it's missing a script/makefile rule that deletes the *.c files and stages the new *.d files instead.
In fact you want something dify HEAD~4..mybranch so you can easily rebase your branch onto the new D based master. Let me quickly write something for that.

[MartinNowak]

@MartinNowak Can you see anything missing from this commit? If not I'll turn it into a pull request.

I had some issues with ROOT_OBJS and root.a b/c of the single file compilation. I ended up making a D_ROOT_SRCS list and compiled that directly into the binary, look at my makefiles.

[MartinNowak]

You're deleting async.c w/o replacement. Intended?

[MartinNowak]

You need to update .gitignore to remove the *.d files

[yebblies]

Yes, I've got a script that I used to generate that commit. I still need to get the auto-update working, which is a little trickier.

I had some issues with ROOT_OBJS and root.a b/c of the single file compilation. I ended up making a D_ROOT_SRCS list and compiled that directly into the binary, look at my makefiles.

I don't understand, what problems? Why doesn't this affect the current DDMD build? Can it be applied to master now before the switch?

You're deleting async.c w/o replacement. Intended?

Yes. It's not needed for a working transition and can be dealt with later.

You need to update .gitignore to remove the *.d files

I don't think that's needed for a working transition.

I'm trying to keep this minimal, with just what's needed so that people can update their PRs. We can make more changes manually after the switch. Are there make targets other than the default and 'auto-tester-build' that are absolutely required for manual or automatic testing?

[MartinNowak]

Yes, I've got a script that I used to generate that commit. I still need to get the auto-update working, which is a little trickier.

See #4922