Update to D 2.068.1 FE

[ibuclaw]

WORK IN PROGRESS

Things carried over from 2.066+2.067 updates, see #99

There is still 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!

Planned changes:

• Remove TREE_THIS_VOLATILE from codegen.
• Update signatures for new lifetime.d routines.
• Update for new RTTI layout (I think).
• Introduction of more intuitively named switches. (E.g: Deprecate -fintfc)

Some end goals (and this is the last release that I aim to get them done by):

• Grouping functions into clearly named source files.
• Adding a namespace gcc { namespace d { } } for common codegen routines, or...
• Encapsulating codegen routines into the Visitor classes, and possibly in the process...
• Replace dt_t* with tree and remove the dt_t** functions
• 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.07x maybe.

Immediate things that need to be done:

• Pass 2.068 the library unittests
• Pass 2.068 the testsuite
• BUG Pass 2.068 the library unittests with optimizations turned on.

[ibuclaw]

List of things backported from later versions of druntime:

• dlang/druntime@d119481
• dlang/druntime@fda62ef
• dlang/druntime@893cc05

[ibuclaw]

There are some CTFE vs runtime assertions being triggered in core.internal.hash and core.internal.convert - I assume this is because CTFE precision of real is higher than runtime (There are 160 mantissa bits represented vs. 64). @MartinNowak - you wrote these if I recall right.

[ibuclaw]

Actually wait, these are regressions from 2.067 -> 2.068. And all that has changed is the frontend... hmm.

[ibuclaw]

Or maybe not...

[ibuclaw]

It's almost as if the unittests are never ran in 2.067, or simply luck makes them pass.

For core.internal.hash failures. It's because toUbytes returns a garbage slice if the input value is a struct literal, as after returning the stack is wiped clean (missing a .dup).

[ibuclaw]

It also fails because you can't rely on padding between fields always being zero.

[ibuclaw]

Ah, I see now why it has been silently passing the unittester, it's because core.internal.xxx modules were never pulled into the final executable because it's was never a dependency.

Wonderful! I wonder how many other bugs are hiding, or it's just these two modules...

[jpf91]

Ah, I see now why it has been silently passing the unittester, it's because core.internal.xxx modules were never pulled into the final executable because it's was never a dependency.

Wonderful! I wonder how many other bugs are hiding, or it's just these two modules...

Maybe we should use --whole-archive when linking our unittests, but I'm not sure if this is 100% portable. Why do we even create libg*_t.a libraries? If we link all *.t.o objects directly into the unittest executable we can probably avoid this issue in a portable way.

[ibuclaw]

Time to rebase against master. Argh!

[ibuclaw]

@jpf91 should I be worried?

Old build system: https://semaphoreci.com/d-programming-gdc/gdc/branches/pull-request-162/builds/11

./unittest
core.exception.AssertError@/home/runner/GDC/libphobos/src/std/conv.d(1042): unittest failure
----------------
core.exception.AssertError@/home/runner/GDC/libphobos/src/std/base64.d(1669): Assertion failure
----------------

New build system: https://semaphoreci.com/d-programming-gdc/gdc/branches/pull-request-162/builds/12

0.004s PASS release64 std.conv

Then I can't rule out that another change fixed it. But if it did, was not directly intentional.

[jpf91]

038613c

base64 also fails in master, but I explicitly disabled the test to match the old build system. The old build system didn't test base64 in 2.067 (the linker stripped the module).

I'm not sure about std.conv. One reason I switched to the new test_runner.d from upstream was that some modules failed depending on compilation order / order in which the modules were tested. I think std.conv was one of these, though I'm not sure.

Upstream and the new build system now only test one module per process, so every module is tested in a clean environment. You could add a printf to the unittest to check if it's really executed though.

[ibuclaw]

Great, now one of the tests no longer compiles because it pulls in a symbol only held by std.net.curl module.

[ibuclaw]

OK, removed the test for now. Let's get in the breaking stuff now.