2.064 std.uni release mode unit tests

[dnadlinger]

On the 2.064 branch, the unit test for std.uni currently fails to build in release mode as the uni.o object from the Phobos library is linked in in addition to the unit test object file, leading to conflicting symbols.

The -why_load option of the OS X ld offers the following clue:

__D3std3uni159__T11TrieBuilderTbTwVi1114112TS3std3uni22__T9sliceBitsVm13Vm21Z9sliceBitsTS3std3uni21__T9sliceBitsVm9Vm13Z9sliceBitsTS3std3uni20__T9sliceBitsVm0Vm9Z9sliceBitsZ11TrieBuilder18__T8addValueVm2TbZ8addValueMFNaNbNebmZv forced load of /Users/aule/Build/Work/ldc2-llvm3.4-debug/lib/libphobos-ldc.a(uni.o)

Investigating…

[dnadlinger]

Can you spot the difference?

_D3std3uni159__T11TrieBuilderTbTwVi1114112TS3std3uni22__T9sliceBitsVm13Vm21Z9sliceBitsTS3std3uni21__T9sliceBitsVm9Vm13Z9sliceBitsTS3std3uni20__T9sliceBitsVm0Vm9Z9sliceBitsZ11TrieBuilder18__T8addValueVm2TbZ8addValueMFNaNbNebmZv
vs.
_D3std3uni159__T11TrieBuilderTbTwVi1114112TS3std3uni22__T9sliceBitsVm13Vm21Z9sliceBitsTS3std3uni21__T9sliceBitsVi9Vi13Z9sliceBitsTS3std3uni20__T9sliceBitsVm0Vm9Z9sliceBitsZ11TrieBuilder18__T8addValueVm2TbZ8addValueMFNaNbNebmZv

The difference is that in the unit test build, sliceBits!(9, 13) is actually mangled as int parameters, whereas the symbol referenced by other Phobos modules is pure nothrow @trusted void std.uni.TrieBuilder!(bool, dchar, 1114112, std.uni.sliceBits!(13uL, 21uL).sliceBits, std.uni.sliceBits!(9uL, 13uL).sliceBits, std.uni.sliceBits!(0uL, 9uL).sliceBits).TrieBuilder.addValue!(2uL, bool).addValue(bool, ulong) with ulong parameters.

Unfortunately, I don't have the time to investigate this further right now.

[redstar]

I compared this to the output of dmd 2.064.2. dmd generates sliceBits!(9, 13) in debug and optimized build. That is a bit surprising.

[redstar]

Same with dmd 2.065.

As I am not an expert in D name mangling: what would be the expected mangling?
The definition is:

struct sliceBits(size_t from, size_t to) { .... }

My assumption was that the mangling uses the type of the type argument. Since size_t is an ulong on 64bit systems, I expected that the constant is cast to an ulong. But experiments reveal that the type of the constant is used: sliceBits(9, 13) is mangled as Vi9Vi13 (i for int) instead of Vm9Vm13 (m for ulong).

Looking at the unit tests I see only int constants used with sliceBits. For me, it looks like an inconsistency in dmd.

[dnadlinger]

This might be related to https://issues.dlang.org/show_bug.cgi?id=3467, and a follow-up bug report I can't find right now. The behavior that integer template parameters would be mangled by the actual type of the literal, without being casted to the parameter types, used to be "by design". We convinced Walter that this is a bad idea, but maybe there are some remnants around still…

[redstar]

The bug report is a good hint. I added a comment about the name mangling.

[dnadlinger]

See my comment there. The bug is supposedly fixed already for D2.

[redstar]

https://issues.dlang.org/show_bug.cgi?id=12720

[redstar]

Fixed with commit e51529c in 0.13.0.