Change Log: 2.095.0

Takes two arguments. The first must be a symbol or expression and the second must be a symbol, such as an alias to a member of parent. The result is member interpreted with its this context set to parent. This is the inverse of __traits(parent, member).

struct A
{
    int i;
    int foo(int j) {
        return i * j;
    }
}

alias Ai = A.i;

void main()
{
    A a;

    __traits(child, a, Ai) = 3;
    assert(a.i == 3);
    assert(__traits(child, a, A.foo)(2) == 6);
}

There were some cases where DMD wasn't able to determine the common type for array literal elements. Mismatched enums and literals containing only mutable and immutable elements should now be correctly inferred.

Every template having at least one instantiation is now printed using standard compiler diagnostics formatting for easy navigation to the point of its declaration.

All messages of this kind are sorted by descending unique instantiation count.

If the flag argument list-instances is passed (such as -vtemplates=list-instances), each location where a template was instantiated is printed along with the reason for the instantiation (implicit or explicit).

For instance, a D source file named main.d containing

void foo(int I)() { }
void goo1(int I)() { }
void goo2(int I)() { goo1!(I); }

void test()
{
    foo!(1)();
    foo!(1)();
    foo!(2)();

    goo1!(1)();

    goo2!(1)();
}

compiled with -vtemplates=list-instances will output

main.d(1): vtemplate: 3 (2 unique) instantiation(s) of template `foo(int I)()` found, they are:
main.d(7): vtemplate: explicit instance `foo!1`
main.d(8): vtemplate: explicit instance `foo!1`
main.d(9): vtemplate: explicit instance `foo!2`
main.d(2): vtemplate: 2 (1 unique) instantiation(s) of template `goo1(int I)()` found, they are:
main.d(11): vtemplate: explicit instance `goo1!1`
main.d(3): vtemplate: implicit instance `goo1!1`
main.d(3): vtemplate: 1 (1 unique) instantiation(s) of template `goo2(int I)()` found, they are:
main.d(13): vtemplate: explicit instance `goo2!1`

The C++ header generated used to write comments when it encountered non-extern(C++) declarations, e.g.

// test.d
void foo() {}

// test.h
[...]
// ignoring function test.foo because of linkage

This caused a lot of bloat in the generated header file and is now customizable via the `-HC= switch which accepts either verbose (write comments) and silent (omit comments). The default was changed to silent.

Note: The header generator is still considerer experimental, so please submit any bugs encountered to the bug tracker.

When writing debug code, one isn't interested statically ensuring that a function block doesn't throw, but a pleasant debugging experience as e.g. writing to the console or logfiles typically can't be nothrow. DMD already allowed to escape pure and @nogc within debug statement. With this release, exception-throwing code can be called from debug statements too:

import std.stdio;
void main() nothrow
{
    debug writeln("Your throwing log statement.");
}

Marking a function with pragma(inline, true) will now cause it to be always inlined when called, and a compile error will result if it cannot be inlined.

If the pragma(inline, true) is embedded in the function body rather than outside it, it may not always take effect. (It depends on whether the function body is analyzed before it is called or not.)

If a function marked with pragma(inline, true) cannot be inlined it will now issue a warning if and only if the -wi command line switch is given. Previously, it would issue an error.

Implicit overrides of base classes methods were deprecated in 2.075.0 (released 2017-07-19) when issue 17349 was fixed by PR 6731.

The deprecation period has now ended and the following code will always error from now:

class Base
{
    void myFunction();
    void myOtherFunction(void* ptr);
}

class Child : Base
{
    // Error: Implicitly overriding `Base.myFunction`
    void myFunction() const;
    // Error: Implicitly overriding `Base.myOtherFunction(void*)`
    void myOtherFunction(const void* ptr);
}

Previously, the compiler allowed any __vector type to be implicitly convertible with any other __vector type.

int4 x = 2;
float8 y = x;
short8 z = y / 3;

In this release, __vector types now, like static arrays, can only be implicitly converted to either qualified types of itself, or void.

const int4 a = 5;
int4 b = a;         // OK, both are int4
void16 c = a;       // OK, cast to void of same size.
float4 d = b;       // Error, cannot implicitly convert int4 to float4.

Explicit conversions between __vector types can be done, but only between vectors of the same size.

long2 a = 8;
short8 b = cast(short8)a;   // OK
short16 c = cast(short16)b; // Error, cannot cast because of different sizes.

Users of the __simd and __simd_sto intrinsics will have to either add explicit casts from void16 to the appropriate type at each use, or operate strictly with void16 vectors until a value is required to be peeked.

float4 fun1(float4 a, float4 b)
{
    a = cast(float4)__simd(XMM.ADDPD, a, b);
    a = cast(float4)__simd(XMM.ADDSS, a, b);
    return a;
}

float4 fun2(void16 a, void16 b)
{
    a = __simd(XMM.ADDPD, a, b);
    a = __simd(XMM.ADDSS, a, b);
    return cast(float4)a;
}

In earlier releases, using in on parameters would be lowered too early, leading to confusing display: error messages would show the parameter as const (or scope const if -preview=in was used), and so would header generations or stack traces. The header generation was problematic, as a header generated with -preview=in would be different from one generated without. From this release, in will now display correctly in every message. As this requires an update to the mangling, some older debuggers or tools might not be able to properly demangle functions that uses in parameters.

Ddoc's Markdown has now been enabled by default. The full list of supported Markdown features (headings, emphasized text, links, and more) is described in the Ddoc documentation page.

For the more cautious, a list of all instances of Markdown features can be logged with -transition=vmarkdown. If you encounter issues with this transition, you can temporarily disable the processing of the Markdown features with -revert=markdown and report an issue.

A huge thanks goes to David Gileadi for championing this issue!

D has supported the in, ref, and out storage classes on parameters since its inception. out and ref are commonly used, however in was usually left behind, as, while it was originally intended as an alias to const scope, it was made an alias to const when support for scope was introduced (DIP1000).

DMD v2.092.0 rectified this by adding -preview=in to mean const scope, as it was originally intended, instead of const without the switch.

However, this didn't really capture the intended meaning of in: the be applied on input parameters. Input parameters are parameters that a function intend to only examine, without modifying it, nor keeping a reference to them around. This is covered by const scope. However, some input parameters can be pretty large, or copying them can have side effects (postblit, copy constructor), hence those should be passed by reference to avoid runtime overhead. Which prompts a new issue: D doesn't support passing rvalues by references. Hence, when designing an API accepting an input parameter, a common practice was to have both an in-accepting overload, and an in ref-accepting one. While this works well for a single parameter, it also suffers from combinatorial explosion.

This release reworks the meaning of in to properly support all those use cases. in parameters will now be passed by reference when optimal, and will accept rvalue. When using the switch, in ref parameters will also trigger an error.

Note that the rules for passing by reference are as follow:

• If the type has an elaborate copy or destruction (postblit, copy constructor, destructor),

• If the type is not copy-able, it will always be passed by reference.
• Reference types (dynamic arrays, function pointers, delegates, associative arrays, classes) do not get passed by ref. This allows for covariance on delegates.
• Otherwise, if the type's size requires it, it will be passed by reference. Currently, types which are over twice the machine word size will be passed by reference, however this is controlled by the backend and can be changed based on the platform's ABI.

Previously, the compiler accepted the following code as being supported by all -mcpu= types on both OSX 32-bit and all 64-bit targets.

__vector(long[4]) x;    // AVX type
x += 1;                 // AVX2 operation

In this release, all __vector types and operations now check the current CPU being targeted for, and will issue an error if there is insufficient support.

This also allows for conditional compilation using __traits(compiles) to probe which operations are supported at compile-time.

static if (__traits(compiles, long4))
{
    // Compiled in if `-mcpu=avx` or higher
}

static if (__traits(compiles, { int4 x; x += 1; }))
{
    // Compiled in if `-mcpu=baseline` or higher
}

static if (__traits(compiles, { int4 x; x *= 1; }))
{
    // Compiled in if `-mcpu=avx` or higher
}

static if (__traits(compiles, { int8 x; x += 1; }))
{
    // Compiled in if `-mcpu=avx2` or higher
}

The following tables describe what minimum -mcpu= level is required.

Since v2.078, some array equality comparisons (e.g., if both arrays are dynamic arrays) have been wrongly using a .tupleof comparison for structs without custom opEquals, basically enforcing -preview=fieldwise for these array comparisons.

union U
{
    string s;
}

void main()
{
    static immutable from = "from", from2 = "from2";
    U[] a = [{ s : from }];
    U[1] b = [{ s : from2[0..4] }];
    assert(a[0] != b[0]);
    assert(a != b);
    assert(a != b[]); // worked before v2.078, been failing since, now working again
}

The new function core.memory.GC.allocatedInCurrentThread() returns the same as core.memory.GC.stats().allocatedInCurrentThread, but is faster, because it avoids calculating other statistics. It is used for -profile=gc and makes it faster, too.

get-path <compiler> has been added as a new action to the install script. This action allows printing information about a compiler binary. The behavior of get-path can be changed with the following additional options:

• --install install compiler if not found locally
• --dmd returns the path of a specific compiler executable (DMD-alike interface)
• --dub returns the path of the DUB executable

Examples

curl https://dlang.org/install.sh | bash -s get-path --install
/home/user/dlang/dmd-2.093.0/linux/bin64/dmd

~/dlang/install.sh get-path ldc-1.23.0 --install
/home/user/dlang/ldc-1.23.0/bin/ldc2

~/dlang/install.sh get-path --dmd ldc --install
/home/user/dlang/ldc-1.23.0/bin/ldmd2

~/dlang/install.sh get-path --dub ldc --install
/home/user/dlang/ldc-1.23.0/bin/dub

~/dlang/install.sh get-path --dub dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

~/dlang/install.sh get-path --dub ldc,dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

If a compiler installation isn't found and --install has not been passed, an error will be issued.

Binary releases for Linux, OSX, and FreeBSD are now built with LDC. This follows the switch to LDC as host compiler for Windows releases with 2.091.0.

Building DMD with LDC should provide a significant speedup of the compiler (20-30%).

This change comes with the following limitations:

• no more FreeBSD 32-bit binary releases (no 32-bit LDC host compiler)
• additional binary tools copied over from previous dmd releases are no longer included (see c0de0295e6b1f9a802bb04a97cca9f06c5b0dccd (optlink still included)) They are still available via https://digitalmars.com/ or from older dmd releases.

Dub will no longer build dynamicLibrary targetType's as staticLibrary.

Except for x86_omf. This has been disabled due to numerous issues that will lead this to not doing what is expected of it.

No compiler or linker flags have been added at this time, you will need to specify the relevant flag to get the compiler to link dynamically against Phobos.

The $DUB_BUILD_PATH variable is now defined inside the postBuildCommands section. It contains the absolute path in which the package was built, and can be used to copy by-products of the build process to their intended locations.

For example, if an executable exports symbols, you will want to make the resulting import library and symbols export file available somewhere. That can be done with a dub.json section like this:

    "postBuildCommands-windows": [
        "copy /y $DUB_BUILD_PATH\\$DUB_TARGET_NAME.lib $PACKAGE_DIR\\lib"
        "copy /y $DUB_BUILD_PATH\\$DUB_TARGET_NAME.exp $PACKAGE_DIR\\lib"
    ],

Now users can use the documented predefined variables inside custom command directives without the need for a wrapper shell script.

Before this would have failed:

"preBuildCommands": ["$DC -run foo.d"]

unless DC was defined as environment variable outside DUB.

It was before possible to run a script that used the $DC environment variable or on POSIX escape the $ with $$DC to make the shell substitute the variable. These workarounds are no longer needed now.

API change: none of the different command directives are no longer substituted with the process environment variables. You now access the raw commands as provided by the user in the recipe. dub describe has been adjusted and now also processes the predefined environment variables as well as the process environment variables.