released Feb 01, 2023
Having multiple definitions of functions within a module had been turnedinto an error in DMD 2.095.0.
However, the compiler would not issue an error when two implementationsdiffered by an explicit and inferred@system attribute, although they havethe same mangling.
void foo() {}void foo() @system {}// no error
This bug has been fixed, and DMD will now issue a deprecation if there are suchconflicting@system function implementations. Starting from DMD 2.112, itwill produce a multiple definition error just like other kinds of conflictingfunctions within a module.
Up until this release,__traits(getAttributes) could be called both onindividual functions and on overload sets. However, in the latter case,the compiler simply collected the user defined attributes for the firstlexically defined function. This behavior is error prone. Consider:
module test;@("gigi")void fun() {}@("mimi")void fun(int) {}void main(){staticforeach(attr;__traits(getAttributes, fun))pragma(msg, attr);
The above code will print "gigi" although there is no indication onwhat overload is actually queried. The first one is always picked.
Starting with this release, this sort of usage of__traits(getAttributes)is deprecated. If a specific overload needs to be handled,__traits(getOverloads)may be used in conjunction with__traits(getAttributes) for proper behavior:
module test;@("gigi")void fun() {}@("mimi")void fun(int) {}void main(){staticforeach (t;__traits(getOverloads, test,"fun"))staticforeach(attr;__traits(getAttributes, t))pragma(msg, attr);
The above code prints:
gigimimi
Thelast clause of afor statementshould not produce a value without also having some meaningfulside-effect. This is now detected with a deprecation message. Thefollowingfor statements each trigger the deprecation:
// evaluating `j` has no side-effectsint j;for (;; j) {...}// unnecessary dereferencefor (ubyte* sp;; *sp++) {...}// first clause is a block statement// last clause is a function literal, not a block statementfor({j = 2;int d = 3;} j + d < 7; {j++; d++;}) {...}
Note: Calling a function returningvoid isnot deprecated even if thefunction does nothing. This is for generic code.
Formerly, they were always allocated with the Garbage Collector, making it unavailable in@nogc or-betterC code.This led to frequent use of the following workaround:
void main() @nogc{int[3] buffer = [10, 20, 30];int[] arr = buffer[];}
This can now be written in a single line:
void main() @nogc{scopeint[] arr = [10, 20, 30];}
With the following limitations:
Some of these limitations might get lifted in the future.
When the condition evaluates to false, any subsequent expressions willeach be converted to string and then concatenated. The resulting stringwill be printed out along with the error diagnostic.
enum e = 3;staticassert(false,"a = ", e);
Will print:
file.d(2): Error: static assert: a = 3
SinceDIP 1035 - System Variables has been accepted, variables marked@system may no longer be accessed from@safe code.To avoid code breakage, the compiler will start with emitting deprecation warnings.The preview switch will turn these into errors, and it will be enabled by default in a future release.
@systemint* p;struct S{ @systemint i;}void main() @safe{int x = *p;// error with `-preview=systemVariables`, deprecation otherwise S s; s.i = 0;// ditto}
Note that currently this is limited to variables explicitly marked@system, inference of@system based on a variable's initializer is yet to be implemented.
The way this works:
The default allocator and deallocator now uses C malloc and free to allocate and deallocate theTraceInfo. Almost everything was already nogc,except for the allocation of theTraceInfo object itself.
The benefits:
One possible drawback is that theTraceInfo is deallocated uponThrowable being finalized, leading to a potential dangling pointer situation. If you do copy theinfo out of theThrowable, makes sure to not keep it beyond the lifetime of theThrowable, or make sure to set theinfoDeallocator member to null.
Newfloat anddouble overloads ofstd.math.exponential.log,std.math.exponential.log10,std.math.exponential.log1p,std.math.exponential.log2, andstd.math.exponential.logbhave been added to Phobos with proper 'software' implementations in thecorresponding precision. Furthermore,std.math.exponential.logb isnowpure.
While this may result in a slowdown in some cases for DMD, the overall speed-upfactor for GDC and LDC is over 3x, for bothdouble andfloat.
This also implies less precise results, especially in single-precision,so if your code depended on more accurate results via 80-bit intermediateprecision, you'll have to cast the argument(s) explicitly now.
If you useunicode.c orunicode.Other (case insensitive) fromstd.uni, you should mitigate or fix your codebase.
This change makes it match theUnicode Techical Report #44. Unfortunately if you are already using it with its previous wrong values, this will break your code, below is a function which reflects the original values that you can use to mitigate against any breakage.
@propertyauto loadPropertyOriginal(string name)()pure{import std.uni : unicode;staticif (name =="C" || name =="c" || name =="other" || name =="Other") {auto target = unicode.Co; target |= unicode.Lo; target |= unicode.No; target |= unicode.So; target |= unicode.Po;return target; }elsereturn unicode.opDispatch!name;}
It is likely that this change will result in breakage in code and program usage.This is due to a number of factors, the tables being updated so significantly and the table generator not having all its changes commited throughout the years.
When Unique goes out of scope, any destructor will now be called.Previously the destructor was not called then.
staticint i;struct S{ ~this() { i++; }}{ Unique!S u =new S;// S.~this now called here}assert(i == 1);
Note: Above, the struct destructor will also be called by the GC justbefore the memory fornew S is reclaimed. Take care that any structdestructor used will handle being called again on the struct.initvalue.
TheVisualD package versionthat the installer downloads hasn't been updated in years. This has been remedied by a versionbump to 1.3.1, the latest release of VisualD.
The NSIS installer for Windows has the option "Add to PATH". Previously, onlythe 32 bit version of DMD was added to the PATH environment variable. Now, onWindows 64 bit, the 64 bit version of DMD will be selected from PATH.
Up until now, dub would output build artifact in the package directory.
This allowed reuse of build artifact for dependencies, but also createdissues with large amount of build artifacts in the packages folder,preventing the use of read-only location to store packages,and making garbage collection of build artifacts unreliable.
Starting from this version, build artifacts will be output by default to$HOME/.dub/cache/build/$BASE_PACKAGE_NAME/$PACKAGE_VERSION/[+$SUB_PACKAGE_NAME]on Linux, and%APPDATA%/cache/build/$BASE_PACKAGE_NAME/$PACKAGE_VERSION/[+$SUB_PACKAGE_NAME]on Windows.
Those two functions were used to provide access to the metadata cache fileto the generator. They were never intended for public consumption,and the JSON file format was not stable.
Due to the introduction of the build cache, they needed to be removed,as there was no way to provide a sensible transition path, and they should be unused.If you have a use case for it, please open an issue in dub repository.
A huge thanks goes to all the awesome people who made this release possible.
