変更ログ 2.106.0

2.104では、修飾子を投げることは廃止された。 非推奨となった。

また、例外をimmutable 、inout 、shared としてキャッチすることも安全ではない。 これは、例外がまだ別の これは、例外がまだ別の共有でない参照を通してアクセス可能かもしれないからである。これらの修飾子で例外をキャッチする で例外をキャッチすることは非推奨となった。

auto e = new Exception("first");
try {
        throw e;
} catch(immutable Exception ie) { // now an error
        e.msg = "second";
        assert(ie.msg == "first"); // would fail
}

以下の機能/バグ修正/改善が に実装された:

• デフォルトの引数コンテキストで使用される静的変数は、完全修飾名を使用して出力されるようになった。 を使うようになった。

注釈: ヘッダー・ジェネレーターはまだ実験的なものである。 バグがあればバグトラッカーに送ってほしい。

このエラーは2.105.0で導入された。

dmd自身は(そしておそらく他のものも)例外をスローしない。 を優先する。しかし、例外がスローされない場合でも例外をサポートするにはコストがかかる。 をサポートすることにはコストがかかる。そのコストとは、RAIIオブジェクトのようなスタック・アンワインダーを追加することである。 オブジェクトのようなものに対してスタック・アンワインダーを追加し、try-catchの境界をまたぐ多くの最適化を妨げることである。

プロジェクト内のすべてのコードにnothrow 。 になる。モジュールの先頭にnothrow: 。 クラスや構造体のメンバ関数のステータスに影響しない。nothrow: をクラスや構造体ごとに繰り返す必要がある。

コンパイラーに-nothrowスイッチを追加すると、スタック・アンワインダーが追加されなくなり、最適化が有効になる。 最適化が有効になる。この機能は-BetterCコードにはすでにある、 この機能は-betterCのコードにはすでにある。

このスイッチはセマンティック解析には影響せず、コード生成だけに影響する。名前のマングリング は影響を受けない。

このスイッチは、例外処理が実行ファイルのサイズやパフォーマンスにどのような影響を与えるかを判断するのに便利である。 サイズとパフォーマンスにどのような影響を与えるかを判断するのに便利である。

CETは、攻撃者がプログラムの制御フローをリダイレクトするのを防ぐのに有効な技術である、 特にIBTは、攻撃者が間接分岐を意図しない場所に行かせることを防ぐ。

インテルIBTは、コンパイラが特別な命令(endbr32 とendbr64)を出すことを期待する。 IBTをサポートしていない古いプロセッサーでは、nop 命令と等価である。 でコンパイルされたプログラムは、どのx86プロセッサーでも互換性があり、保護機能はサポートされているプロセッサーで日和見的に有効になる。

DMDでインテルIBTプロテクションを有効にするには、-fIBT フラグをコンパイラに渡す必要がある。 その結果、コンパイラーは自分でIBTのための命令の放出を管理することになる。 インライン・アセンブリを使用する場合は注意が必要で、コンパイラーはインライン・アセンブリ内のIBTを自動的に処理しない。

Dプログラム内でIBTが有効になっているかどうかを調べるには、次のようにgetTargetInfoを使用する:

// IBTはアクティブ
static assert(__traits(getTargetInfo, "CET") == 1);  // IBTがアクティブならCET == 1

// IBTはアクティブでない
static assert(__traits(getTargetInfo, "CET") == 0);  // IBTがアクティブでないならCET == 0

問題23145の修正は既存のコードを壊したので、他のscope 関連のエラーと同様に、現在は-preview=DIP1000 の後ろに置かれている。

immutable データと同様に、グローバルconst データはスレッド・ローカル・ストレージ(TLS)に置かれないため、スレッド・ローカルの静的コンストラクタで初期化するとconst に違反することになる: 詳細はissue 24056を参照のこと。 これを行うと、非推奨になる:

int x;
const int y;
immutable int z;

static this()
{
    x = 1;
    y = 2; // 非推奨: const変数を変更できない
    z = 3; // エラー: 不変変数を変更できない(以前と同じ)
}

是正措置として、初期化を共有の静的コンストラクタに移す:

const int y;

shared static this()
{
    y = 4; // OK
}

これまでは、連想配列を使ってグローバル変数を初期化するには、モジュールのコンストラクタかenum 。 内部的にSteven Schveighofferのnewaa構造体の実装を下げることで、連想配列が直接使えるようになった。

immutable string[string] table = ["key": "value"];

void main()
{
    assert(table["key"] == "value");
}

キー/値型にtoHash 、opEquals 、~this が定義されている場合、それらはコンパイル時に呼び出し可能でなければならない。 if (!__ctfe) 。デストラクタを実行時にのみ実行させるために、 分岐を使用することができる。 将来の機能拡張によって、この回避策が不要になるかもしれない。

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

_d_newarrayU は上記の両方のフックの汎用実装であり、単に配列を確保するだけである。 で使用されているため、 には組み込まれていない。 現在、 はまだ非テンプレートの を使用している。 将来のPRでは、新しいテンプレートを使用するように を更新する予定である。 dup _d_newarrayT dup _d_newarrayU dup

これで、コンパイラーは以下のように下げる:

S[] s = new S[10]

// is now lowered to:
S[] s = _d_newarrayT!S(10);

この変更により、core.internal.array.construction に新しいテンプレートが追加された。 さらに、core.internal.array.utils のテンプレート__arrayClearPad 、__arrayAlloc 、__arrayStart 、__setArrayAllocLength を実装する。 __arrayClearPad と__arrayStart もrt.lifetime から削除された。 その他のテンプレートは、TypeInfo の引数を受け取り、rt.lifetime の他のフックによって呼び出されるため、まだ削除できない。

• GC.enable
• GC.disable
• GC.collect
• GC.minimize

以前は、etc.c.odbcバインディングは非推奨で、public import経由でcore.sys.windowsバージョンのバインディングを転送していた。しかし、ODBCはすべての主要なプラットフォームでサポートされており、core.sys.windowsの機械翻訳されたMinGWバインディングにはversion(Windows)が指定されているため、Windows以外のプラットフォームではこれらのバインディングを使用することができない。このバインディングはetc.c.odbcに戻され、非推奨になり、Windows以外のプラットフォームのサポートが有効になった。

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

Unshared は、 に相当する。 の外側のレイヤーを取り除く。 shared Unconst shared

    static assert(Unshared!(shared int) == int);
    static assert(Unshared!(shared(int[])) == shared(int)[]);

つまり、Unconst は、const 、immutable 、inout の外層を剥ぎ取る; Unshared shared Unqual の外側のレイヤーを取り除く。 型修飾子 "を取り除く。

このフラグを指定することで、すべての依存関係をビルドできるようになった。 をビルドできるようになった。デフォルトでは のルートディレクトリにあるライブラリのみをビルドする。 ファイルのルートディレクトリにあるライブラリのみをビルドする。これにより、ライブラリのビルドを必要とする他のビルドシステム との統合をより良くする。

dub build --deep

staticLibraryAがstaticLibraryBに依存している場合、--deep フラグが指定されている場合、dubはAとBの両方のライブラリを出力する。

• default-config は単一の文字列で、 のような単純な呼び出しで何もコンフィギュレーションが提供されない場合に DUB が選ぶ のコンフィギュレーションとなる。dub build --config
• configs は利用可能なすべてのコンフィギュレーション(デフォルトで生成されたアプリケーションやライブラリ、またはレシピで手動で指定されたもの)のリストである。
• default-build は、何も提供されなかったときにDUBが選ぶ ビルド型を表す単一の文字列である(現在は常に "debug")。--build
• builds は利用可能なすべてのビルド型のリストである(ビルトイン＋カスタム定義)。

dub init を使ってパッケージを作成する際に、パッケージのライセンスを選択するプロンプトが表示されるようになった。

デフォルトの dub.sdl とdub.json 。つまり、複数のdub.jsonファイルを定義することができる。 を定義することができる。 CLI上で使用するものを選択できる。

dub build --recipe=custom-dub.json

これは、dub.jsonよりもdub.sdlを選ぶ場合にも使える。 を選ぶために使うこともできる。しかし、これは他の DUBをサポートする他のツールとの相互運用性や、ユーザーの一般的な混乱を避けるために推奨されない。両方が同時に存在する 同時に存在する場合も、将来このスイッチが指定されないとエラーになる可能性がある。