Change Log: 2.093.0

Those switched were already not doing anything and had been deprecated for a while. The compiler will no longer recognized them.

GNU ABI tags are a feature that was added with C++11 in GCC 5.1. In order for D to fully support the standard C++ library, DMD now recognize the special UDA gnuAbiTag, declared in core.attribute and publicly aliased in object (so one need not import anything to use it). The ABI tags are a low level feature that most user will not need to interact with, but can be used to bind to C++ libraries that need it. In particular, it is required to bind std::string when targeting C++11 and higher (DMD switch -extern-std={c++11,c++14,c++17}).

It can be used in the following way:

extern(C++):
@gnuAbiTag("tagOnStruct")
struct MyStruct {}
@gnuAbiTag("Multiple", "Tags", "On", "Function")
MyStruct func();

Only one gnuAbiTag can be present on a symbol at a time. The order of the array entries does not matter (they are sorted on output). The UDA will only have an effect if -extern-std=c++11 or higher is passed to the compiler. The default (-extern-std=c++98) will ignore the UDA. This UDA can only be applied to extern(C++) symbols and cannot be applied to namespaces.

Module constructors and destructors (shared or not) could be marked with a different linkage than extern(D), which would affect their mangling. Since such a mangling is simple and predictable, there was a very small chance of conflict if two same kind of constructor/destructors were declared in similar condition, for example if the third module constructor in module a was on line 479 and the third module constructor in module b was also on line 479, they would have the same mangling.

While it's unlikely that such a bug is triggered in practice, affected symbols will now trigger a deprecation message.

DIP25 has been available since v2.067.0, first as its own switch, and more recently under the -preview=dip25 switch. The feature is now fully functional and has been built on, for example by DIP1000.

Starting from this release, code that would trigger errors when -preview=dip25 is passed to the compiler will also trigger a deprecation message without -preview=dip25. The behavior of the switch is unchanged (errors will still be issued).

DIP25 aims to make it impossible for @safe code to refer to destructed object. In practice, functions and methods returning a ref to their parameter might be required to qualify the method or the parameter as return, as hinted by the compiler.

struct Foo
{
    int x;
    // returning `this.x` escapes a reference to parameter `this`, perhaps annotate with `return`
    ref int method() /* return */ { return this.x; }
}
// returning `v` escapes a reference to parameter `v`, perhaps annotate with `return`
ref int identity(/* return */ ref int v) { return v; }

In both cases, uncommenting the return annotation will appease the compiler. The complete description of DIP25 can be found here.

An Ownership/Borrowing (aka OB) system for pointers can guarantee that dereferenced pointers are pointing to a valid memory object.

Scope of Prototype OB System

This is a prototype OB system adapted to D. It is initially for pointers only, not dynamic arrays, class references, refs, or pointer fields of aggregates. Adding support for such adds complexity, but does not change the nature of it, hence it is deferred to later. RAII objects can safely manage their own memory, so are not covered by OB. Whether a pointer is allocates memory using the GC or some other storage allocator is immaterial to OB, they are not distinguished and are handled identically.

The system is only active in functions annotated with the @live attribute. It is applied after semantic processing is done as purely a check for violations of the OB rules. No new syntax is added. No change is made to the code generated. If @live functions call non-@live functions, those called functions are expected to present an @live compatible interface, although it is not checked. if non-@live functions call @live functions, arguments passed are expected to follow @live conventions.

The OB system will detect as errors:

• dereferencing pointers that are in an invalid state
• more than one active pointer to a mutable memory object

It will not detect attempts to dereference null pointers or possibly null pointers. This is unworkable because there is no current method of annotating a type as a non-null pointer.

Core OB Principle

The OB design follows from the following principle:

For each memory object, there can exist either exactly one mutating pointer to it, or multiple non-mutating (read-only) pointers.

Design

The single mutating pointer is called the "owner" of the memory object. It transitively owns the memory object and all memory objects accessible from it (i.e. the memory object graph). Since it is the sole pointer to that memory object, it can safely manage the memory (change its shape, allocate, free and resize) without pulling the rug out from under any other pointers (mutating or not) that may point to it.

If there are multiple read-only pointers to the memory object graph, they can safely read from it without being concerned about the memory object graph being changed underfoot.

The rest of the design is concerned with how pointers become owners, read only pointers, and invalid pointers, and how the Core OB Principle is maintained at all times.

Tracked Pointers

The only pointers that are tracked are those declared in the @live function as this, function parameters or local variables. Variables from other functions are not tracked, even @live ones, as the analysis of interactions with other functions depends entirely on that function signature, not its internals. Parameters that are const are not tracked.

Pointer States

Each pointer is in one of the following states:

Undefined

If an Owner pointer is assigned to another Owner pointer, the former enters the Undefined state.

A Borrowed pointer must have the scope attribute and must be a pointer to mutable.

Lifetimes

The lifetime of a Borrowed or Readonly pointer value starts when it is first read (not when it is initialized or assigned a value), and ends at the last read of that value.

This is also known as Non-Lexical Lifetimes.

Pointer State Transitions

A pointer changes its state when one of these operations is done to it:

• storage is allocated for it (such as a local variable on the stack), which places the pointer in the Undefined state

Although technically defined to be const scope, the in storage class has never been implemented as such until this preview switch. With the implementation now done, in should be the storage class of choice for purely input function parameters.

Without -preview=in, these two declarations are equivalent:

void fun(in int x);
void fun(const int x);

With -preview=in, these two declarations are equivalent:

void fun(in int x);
void fun(scope const int x);

Follows the C99 specification 7.19.6.1 for printf and 7.19.6.2 for scanf.

For printf, it takes a generous, rather than strict, view of compatiblity. For example, an unsigned value can be formatted with a signed specifier.

For scanf, it takes a strict view of compatiblity.

Diagnosed incompatibilities are:

1. incompatible sizes which will cause argument misalignment
2. deferencing arguments that are not pointers
3. insufficient number of arguments
4. struct arguments
5. array and slice arguments
6. non-pointer arguments to s specifier
7. non-standard formats
8. undefined behavior per C99

Per the C Standard, extra arguments are ignored.

No attempt is made to fix the arguments or the format string.

In order to use non-Standard printf/scanf formats, an easy workaround is:

printf("%k\n", value);  // error: non-Standard format k

const format = "%k\n";
printf(format.ptr, value);  // no error

Most of the errors detected are portability issues. For instance,

string s;
printf("%.*s\n", s.length, s.ptr);
printf("%d\n", s.sizeof);
ulong u;
scanf("%lld%*c\n", &u);

should be replaced with:

string s;
printf("%.*s\n", cast(int) s.length, s.ptr);
printf("%zd\n", s.sizeof);
ulong u;
scanf("%llu%*c\n", &u);

Printf-like and scanf-like functions are detected by prefixing them with pragma(printf) for printf-like functions or pragma(scanf) for scanf-like functions.

In addition to the pragma, the functions must conform to the following characteristics:

1. be extern (C) or extern (C++)
2. have the format parameter declared as const(char)*
3. have the format parameter immediately precede the ... for non-v functions, or immediately precede the va_list parameter (which is the last parameter for "v" variants of printf and scanf)

which enables automatic detection of the format string argument and the argument list.

Checking of "v" format strings is not implemented yet.

The environment variable SOURCE_DATE_EPOCH is used for reproducible builds. It is an UNIX timestamp (seconds since 1970-01-01 00:00:00), as described here. DMD now correctly recognize it and will set the __DATE__, __TIME__, and __TIMESTAMP__ tokens accordingly.

TypeInfo_Class.isBaseOf returns true if the argument and the receiver are equal or if the class represented by the argument inherits from the class represented by the receiver. This is called isBaseOf instead of isAssignableFrom to avoid confusion for classes that overload opAssign and so may allow assignment from classes outside their inheritance hierarchy and to match existing terminology in the D runtime. TypeInfo_Interface.isBaseOf is similar with the addition that the argument may be either TypeInfo_Class or TypeInfo_Interface.

class ClassA {}
class ClassB : ClassA {}

auto a = new ClassA(), b = new ClassB();

assert(typeid(a).isBaseOf(typeid(a)));
assert(typeid(a).isBaseOf(typeid(b)));
assert(!typeid(b).isBaseOf(typeid(a)));

pageSize contains the size of a system page in bytes.

import core.memory : pageSize;
ubyte[] buffer = new ubyte[pageSize];

minimumPageSize contains the minimum size of a system page in bytes.

This is a compile time, platform specific value. This value might not be accurate, since it might be possible to change this value. Whenever possible, please use pageSize instead, which is initialized during runtime.

The minimum size is useful when the context requires a compile time known value, like the size of a static array: ubyte[minimumPageSize] buffer.

import core.memory : minimumPageSize;
ubyte[minimumPageSize] buffer;

It is now possible to convert from the ISO 8601 week calendar into the Gregorian calendar which is used by Date and DateTime.

Dates are constructed from the year in the ISO week calendar, the week number and a day of week. Date.fromISOWeek(2020, 11, DayOfWeek.mon) will result in Date(2020, 3, 9).

As the year in the Gregorian calendar and the year in the ISO week calendar are not always the same there is a new .isoWeekYear property to get the year of the Date object in the ISO week calendar. If you convert between them often, consider using .isoWeekAndYear to compute both week number and year in one step.

The module std.xml has been deprecated. Any code that still needs it can use UndeaD instead. For parsing xml files, we recommend to use the dub package dxml.

They were deprecated since 2.076.1 and have now been removed. Import std.digest or its submodules instead.

Additionally the deprecation cycle for std.digest.digest was started and the module will be removed in 2.101.

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.