Update to D 2.067.1 FE

[ibuclaw]

WORK IN PROGRESS

You may notice that there is a lacking of actual merging of DMD here. That's because it's not being committed yet.

There is a lot of catching up to do with regards to moving most things over to either free functions, double-dispatch visitors, or removing a whole range of stubs entirely!

This leaves some nice room in GDC to do a better clean-room redesign in some places. Whilst starting from scratch is not really an immediate option, what I'll instead do it put up the scaffolding and slowly / surely move things across.

Some things I'd like to end up with are:

• Grouping functions into clearly named source files.
• Using .cc for sources that interact with the frontend, and...
• Using .c for sources for independent GDC code generation.
• Adding a namespace gcc { namespace d { } } for common codegen routines, or...
• Encapsulating codegen routines into the Visitor classes, and possibly in the process...
• Remove IRState entirely, or merge it's routines as part of a bigger structure / Visitor, same goes also goes for...
• dt_t* being replaced with tree and remove the dt_t** functions, or merge toDt with the general toElem codegen routines.
• It would also be nice to remove Symbol, and block, but that will have to wait until 2.069 maybe.

Immediate things that need to be done:

• Pass 2.067 the library unittests
• Pass 2.067 the testsuite
• Pass 2.067 the library unittests with optimizations turned on.

[ibuclaw]

Removed this fantastic hack:

#ifdef optimize
#undef optimize
#endif

Now use of the frontend ::optimize method is no longer permitted in GDC. Instead, use ctfeInterpret to get the value constant.

[ibuclaw]

Removed ArrayScope helper, and instead of binding index/slices around __dollar, instead it's treated as a placeholder for the real length. This has resulted in overall better codegen and back-end branch prediction.

[ibuclaw]

Also removed all other codegen helpers that no longer have any benefit.

[ibuclaw]

@jpf91 - Feel free to have a look here: ibuclaw@f83b832

I'll leave it at that for the moment, but thought I might get a second opinion on encapsulating routines that use IRState into IRVisitor before I go ahead and complete it.

[jpf91]

LGTM. I think that's the right approach in the long term.

[ibuclaw]

OK - maintaining this PR is clearly not going to work in the long run, so I'm going to merge in some stuff early once there is a nice window open to do so.

[ibuclaw]

OK, let's get this in. Just to allow anyone to iron out any bugs in master before trickling it down to other branches.

[jpf91]

Great! Have you already tested ARM builds?

[ibuclaw]

Not yet, but I imagine I should pull in the 2.068 druntime C bindings.

[MartinNowak]

Yay!
BTW, could anyone update http://gdcproject.org/downloads/LATEST please?

[ibuclaw]

No downloads are available yet.

[jpf91]

@ibuclaw this has introduced 40 new unresolved tests on semaphore. Are these all caused by the missing C++ compiler on semaphore?
https://semaphoreci.com/d-programming-gdc/gdc/branches/master/builds/61

[ibuclaw]

Hmm, I have not come across that before in my local testing.

[ibuclaw]

Nope, it was #160 that introduced the regression.

[ibuclaw]

It happens because FuncAliasDeclaration::toSymbol doesn't set it's own csym. It was likely a mistake on my part to assume that it would be set anyway.

[ibuclaw]

Ah, I was looking at the wrong output.

I've added the following to our build commands:

grep -q FAIL gcc/testsuite/gdc/gdc.sum && false ||:
grep UNRESOLVED gcc/testsuite/gdc/gdc.sum ||:

I hope this should do the right thing™

[MartinNowak]

BTW, could anyone update http://gdcproject.org/downloads/LATEST please?

There is already a 5.2 w/ the 2.066.1 FE, but Travis-CI is still on 4.9.3.

[ibuclaw]

Maybe wait for travis to roll out the next LTS version of Ubuntu? I'm a bit weary of ABI changes in g++-5 will start breaking stuff. In particular the C++ tests in the testsuite.

[MartinNowak]

Maybe wait for travis to roll out the next LTS version of Ubuntu?

They didn't change that ever and would get into many more troubles by doing it, so you'll wait a very long time. If the latest gdc version isn't compatible with older g++ versions, then people at least know they have to use an older version and can explicitly select gdc-4.9.3.
The main idea behind dmd, dmd-beta, dmd-nightly, gdc, and ldc is that people can automatically test their library for compatibility with the latest released version.

[ibuclaw]

The main idea behind dmd, dmd-beta, dmd-nightly, gdc, and ldc is that people can automatically test their library for compatibility with the latest released version.

Ah, I thought you meant for building just ddmd.