変更ログ: 2.107.0

文字列リテラルのブーリアン評価は、意図せずに行われる可能性がある。 例えば、assert(0, "message") を意味していたのに、0 が抜けていた場合など。

assert("unexpected runtime condition");
static assert("unhandled case for `", T, "`");

この2つのアサートは、無言のまま常に何の効果ももたらさなかった。 現在では、これらのケースは非推奨メッセージで検出される。 元の挙動が実際に意図されていたのであれば、代わりにexpr !is null :

assert("" !is null);
static assert("" !is null);

コンパイラをビルドするための Makefile (compiler/src/{posix,win32,win64}.mak) はしばらく非推奨とされていたが、ついに削除された。現在は、compiler/src/build.d ツールを直接使うか(docsを参照)、LDCホストコンパイラを使った最適化ビルドの場合など、リポジトリのルートにあるトップレベルのMakefileを使って、コンパイラとdruntimeをワンステップでビルドしてほしい:make -jN HOST_DMD=ldmd2 ENABLE_RELEASE=1 ENABLE_LTO=1

トップレベルの Makefile の名前がposix.mak からMakefile に変更された(非推奨のposix.mak フォワーダーを使用)。例えば、druntime はtest 、install 、clean ターゲットに含まれるようになった。

従来のsrc/posix.mak ファイルはまだ存在するが、トップレベルの Makefile に転送される。そのため、例えばデフォルトのall ターゲットには、コンパイラーだけでなくdruntimeも含まれるようになった。

トップレベルwin{32,64}.mak とレガシーsrc/win{32,64}.mak ファイル(DigitalMars make用)は完全に削除された。一般的なトップレベルMakefile は、GNU make(とbashとGNUツールを提供するgitのインストール)で、Windowsでも動作する。

長い間非推奨だったcompiler/test/Makefile も削除された。代わりにcompiler/test/run.d を直接使う(docsを参照)。

以前は、-ignore dmdスイッチを使わない限り、認識されないプラグマはハードエラーを発していた。現在は常に無視され、-ignore dmdスイッチも無視される。

2つのモジュールが互いにインポートしていて、両方がモジュールコンストラクタを持っている場合、 druntimeはどちらを先に実行するか判断できないため、エラーを投げる。

これはpragma(crt_constructor) 、回避することができるが、C言語のランタイム・コンストラクタでは、druntimeは初期化されない。 そのため、このようなコンストラクターではガベージ・コレクターを使うことができない。

@standalone は新しい属性で、druntimeが初期化された後に実行されるモジュールコンストラクタをマークするために使用できる、 で、druntimeが初期化された後に実行されるが、その前に実行される他のモジュールコンストラクタに依存しないモジュールコンストラクタをマークするために使用できる新しい属性である。 からインポートする必要がある。 core.attribute

コンパイラーは、モジュールのコンストラクターが本当に初期化される他の変数に依存していないことを検証しないので、手動で強制しなければならない。 そのため、@system または@trusted とマークしなければならない。

import core.attribute : standalone;

immutable int* x;

@standalone @system shared static this()
{
    x = new int(10);
}

void main()
{
    assert(*x == 10);
}

可能であれば、@standalone を使う代わりに、問題のあるモジュールのコンストラクタをそれ自身の小さなモジュールに入れることで、循環依存エラーを解決したい。

_d_newarraymTX テンプレートは、DBIを使用して、配列の要素の型によってどのタイプの初期化子が必要かをチェックするようになった。 したがって、これは_d_newarraymTX と_d_newarraymiTX の両方を置き換える。

_d_newarrayOpT は、上記の両方のフックの一般的な実装であった。 まず「外側」の配列をポインタ配列として確保し、次に または を呼び出して、「内側」の1次元配列を適宜初期化していた。 現在では、 と のマージにより、これは不要となった。 _d_newarrayT _d_newarrayiT _d_newarraymTX _d_newarraymiTX

現在、コンパイラーは以下のような下降を実行する:

S[][] s = new S[][](2, 3)

// is now lowered to:
S[] s = _d_newarraymTX!(S[][], S)([2, 3]);

この変更により、新しいテンプレートがcore.internal.array.construction に追加される。

以下のcore.atomic 関数がより制限的になった:

1. atomicLoad と 、インスタンス化されることを拒否するようになった。atomicStore

ほとんどの場合、これまでMemoryOrder.acq_rel を使っていたコードは、代わりに を使うように切り替えるべきである。 MemoryOrder.seq に切り替えるべきである。

// エラー:
atomicLoad!(MemoryOrder.acq_rel)(src);
atomicStore!(MemoryOrder.acq_rel)(dest, value);

// 修正アクション:
atomicLoad!(MemoryOrder.seq)(src);
atomicStore!(MemoryOrder.seq)(dest, value);

// または:
atomicLoad(src);
atomicStore(dest, value);

2. atomicExchange という引数でインスタンス化されることを拒否するようになった。

ほとんどの場合、MemoryOrder.acq を使っていたコードは、代わりに MemoryOrder.seq に切り替えるべきである。

// エラー:
atomicExchange!(MemoryOrder.acq)(dest, value);

// 修正アクション:
atomicExchange!(MemoryOrder.seq)(dest, value);

// または:
atomicExchange(dest, value);

3. atomicCompareExchangeWeak そして、 、現在は拒否している。atomicCompareExchangeStrong

ほとんどの場合、これらのどちらかを使用していたコードは、代わりに MemoryOrder.raw に切り替えるべきである。

// エラー:
atomicExchangeWeak!(MemoryOrder.rel, MemoryOrder.rel)(dest, compare, value);
atomicExchangeWeakNoResult!(MemoryOrder.acq_rel, MemoryOrder.acq_rel)(dest, compare, value);
atomicExchangeStrong!(MemoryOrder.acq, MemoryOrder.rel)(dest, compare, value);
atomicExchangeStrongNoResult!(MemoryOrder.seq, MemoryOrder.acq_rel)(dest, compare, value);

// 修正アクション:
atomicExchangeWeak!(MemoryOrder.rel, MemoryOrder.raw)(dest, compare, value);
atomicExchangeWeakNoResult!(MemoryOrder.acq_rel, MemoryOrder.raw)(dest, compare, value);
atomicExchangeStrong!(MemoryOrder.acq, MemoryOrder.raw)(dest, compare, value);
atomicExchangeStrongNoResult!(MemoryOrder.seq, MemoryOrder.raw)(dest, compare, value);

4. atomicCompareExchangeWeak と を追加した。atomicCompareExchangeStrong

ほとんどの場合、この契約に違反するコードは、 と の両方の引数に同じ MemoryOrder を使用すべきである。 succ fail を使うべきである。

// エラー:
atomicExchangeWeak!(MemoryOrder.raw)(dest, compare, value);
atomicExchangeStrong!(MemoryOrder.acq, MemoryOrder.seq)(dest, compare, value);

// 修正アクション:
atomicExchangeWeak!(MemoryOrder.raw, MemoryOrder.raw)(dest, compare, value);
atomicExchangeStrong!(MemoryOrder.acq, MemoryOrder.acq)(dest, compare, value);

{posix,win32,win64}.mak Makefileは一般的なMakefile (druntime/test/ のものを含む)にマージされた。posix.mak は今のところ非推奨のフォワーダーとして残してある。

Windowsでは、GNU make (とbashとGNUツールを提供するgitインストール)を使って、一般的なMakefileを使うことができる/使う必要がある。Windowsの開発者は、-j を使ってようやく並列性を利用できるようになる!https://github.com/dlang/dmd/releases/download/nightly/gnumake-4.4-win64.zip からzip圧縮済みの.exeをダウンロードできる。

このモジュールの目的は、CからDへのコード移植作業を支援し、システムCコンパイラー対応と可能な限り同じコード生成を行うことである。

関数名のエイリアスが存在しない場合、コード生成の品質を気にしないのであれば、_impl を追加して実装を見ることができる。

もしある関数が提供するコード生成がシステムCコンパイラーと同等でなく、それがあなたのユースケースにとって重要であれば、バグとして報告してほしい。

isForwardRangeにオプションの2番目のテンプレート・パラメータが追加された。 をvoidに設定するようになった。voidでない場合、範囲の要素型がこの追加引数constと同じ型である場合にのみtrueと評価される。 型がこの追加引数と同じである場合にのみ真と評価される。例えば 例えば、isForwardRange!(int[], const(int)) は真だが isForwardRange!(int[], string) は偽である。

{posix,win32,win64}.mak Makefileは一般的なMakefile にマージされた。posix.mak は今のところ非推奨のフォワーダーとして残してある。

Windowsでは、GNU make (とbashとGNUツールを提供するgitインストール)を使って、一般的なMakefileも使える/使う必要がある。Windowsの開発者は、-j を使ってようやく並列性を利用できるようになる!https://github.com/dlang/dmd/releases/download/nightly/gnumake-4.4-win64.zip からzip圧縮済みの.exeをダウンロードできる。