Change Log: 2.097.0

The compiler has been updated to return the real part of creal numbers in ST0, and the imaginary part in ST1, to match the x86_64 System V ABI.

This is an ABI breaking change and requires recompiling libraries that make use of the creal type.

This allows code interfacing with C and C++ to maintain ABI compatibility with _Complex types. It replaces the built-in types cfloat, cdouble, and creal which are due to be deprecated.

Up until this release, the postblit had priority over the copy constructor, no matter if the former was user-defined or generated. This prevented new code that uses the copy constructor to interact with library code that uses the postblit. To enable this interaction, having a generated postblit and a copy constructor (user-defined or generated) is now deprecated. For example:

// library code using postblit
struct A
{
    this(this) {}
}

// new code using copy constructor
struct B
{
    A a;
    this(const scope ref B) {}
}

Up until this release, in the above code, struct B had a generated postblit that had priority over the user defined copy constructor. With this release, a deprecation will be issued at the definition of structB, stating that the postblit is going to be preferred to the copy constructor. If B has both a user-defined postblit and a copy constructor (generated or user-defined), the postblit will continue to have priority.

To get rid of the deprecation, the user can either:

1. Explicitly @disable this(this) in struct B. That will instruct

2. Define a postblit for struct B. That will instruct the compiler

3. Remove all copy constructors from struct B. In this case the postblit

In previous release, the JSON output the compiler generates did not include the protection level if it was public. It is now always included.

Previously, module constructors and destructors (shared or not) would be output as functions, and the only way for documentation generators to recognize them was to search for the pattern that was used for their naming. This means that external tools would need to depend on internal compiler details for generating documentation. From this release, 4 new values have been introduced for kind: shared static constructor, shared static destructor, static constructor, static destructor.

Support for instantiating local and member templates with local symbols was implemented in DMD 2.087.0. However, the implementation was incompatible with GDC and LDC backends.

In order to maintain feature parity among D implementations, this improvement has been deprecated, and may be removed from a future DMD release.

The following features/bugfixes/improvements were implemented for the experimental C++ header generator:

• Generate fieldwise constructors for aggregates
• Don't emit instantiated classes as unique class declarations
• Emit template arguments for instantiated base classes
• Don't emit enums for opaque types specially handled by the compiler

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

Emit DWARF symbolic debug info (non-Windows machines only). Supported versions are 3, 4, and 5.

Once added, the -g switch is implicitly activated.

Note: DWARF Version 5 is experimental.

Since the changes in v2.071.0, attributes such as private, protected, public, etc... are visibility attributes, and not protection attributes. However, the name of this trait predates such change and was thus inconsistent with all the other documentation. This change only introduce the new name, and getProtection has been left un-deprecated, and while using the new name is reccommended for users that only supports the latest version of the language, there is no plan to deprecate it.

Synchronized statements have two forms, synchronized and synchronized(exp). When there is no expression argument, a global mutex is created using a static buffer big enough to store the platform dependant critical section type and a pointer field.

Example:

void main()
{
    synchronized {
        // __gshared byte[40 + 8] __critsec;
        // _d_criticalenter(&__critsec[0]);
        // scope(exit) _d_criticalexit(&__critsec[0]);
        (cast() counter) += 1;
    }
}

This implementation suffers from a couple deficiencies. Neither the size nor alignment of the critsec buffer are obtained from the OS critical section type defined in druntime. As a result, if the size allocated by the compiler is too small, or the platform has strict alignment requirements, then the program run-time will crash on entering the synchronized statement.

This code will now call a new implementation that allocates the critical section lazily at run-time, moving all logic out of the compiler to druntime.

-preview=shortenedMethods is added. This allows functions to be written in a similar form to lambda functions:

// these 2 are equivalent
int foo() { return 1; }
int foo() => 1;

The syntax allows the form => expr to replace the function body { return expr; }

It had been deprecated in 2.088.

It had been deprecated in 2.082 in favor of core.sys.freebsd.sys.mount.

Currently, druntime uses the backtrace and backtrace_symbols functions to provide debug informations (addresses and function names, respectively).

This can create issues for target that do not provide backtrace, such as Musl libc. Additionally, the backtrace interface is inherently limited, as it only allow to get up to X frames (where X is the size of the buffer), and forces them to be stored continuously in memory. The same apply to backtrace_symbols.

On the other hand, libunwind is an industry standard for unwinding and stack trace inspection. It has been ported to a variety of platform, has a simple yet flexible API, and is part of GCC, and a similar library is part of LLVM.

Starting from this release, druntime includes a way to use LLVM's libunwind as a backtrace provider. The support is limited to LLVM's version of libunwind, as it is available on Alpine Linux, and easier to interface with.

For packagers, one can define DRuntime_Use_Libunwind when building druntime, enabling the support by default.

The template approxEqual for comparing floating point numbers has been deprecated.

Please use the template isClose instead, which has better default values and is symmetric in its arguments.

To (almost) keep the current behaviour of approxEqual(a, b) use isClose(a, b, 1e-2, 1e-2), but we recommend to adjust the code to make it work with isClose(a, b).

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.