変更ログ 2.102.0

モジュール内に複数の関数定義があると、DMD 2.095.0ではエラーになっていた。 DMD 2.095.0ではエラーになっていた。

しかし、2つの実装が明示的で推論される 属性によって異なっていても、コンパイラはエラーを出さなかった。 つの実装が同じマングリングであるにもかかわらず、明示的な@system 属性と推論される 属性によって異なる場合、コンパイラーはエラーを出さない。 同じマングリングである。

void foo() {}
void foo() @system {} // エラーなし

このバグは修正され、DMDは現在、このような競合する このバグは修正され、DMDはこのような@system 関数の実装が矛盾する場合、非推奨を発行するようになった。DMD 2.112からは モジュール内で競合する他の種類の関数と同じように、多重定義エラーとなる。 関数と同じように多重定義エラーとなる。

このリリースまで、__traits(getAttributes) は個々の関数とオーバーロード・セットの両方で呼び出すことができた。 を呼び出すことができた。しかし、後者の場合 のユーザー定義属性を収集するだけである。 のユーザー定義属性を収集するだけであった。この動作はエラーを起こしやすい。考えてみよう:

module test;

@("gigi")
void fun() {}
@("mimi")
void fun(int) {}

void main()
{
    static foreach(attr; __traits(getAttributes, fun))
        pragma(msg, attr);

上記のコードは "gigi"と表示される。 と表示される。常に最初のものが選ばれる。

このリリースから、このような__traits(getAttributes) は非推奨である。特定のオーバーロードを処理する必要がある場合、__traits(getOverloads) を__traits(getAttributes) と併用することで、適切な動作を実現できる:

module test;

@("gigi")
void fun() {}
@("mimi")
void fun(int) {}

void main()
{
    static foreach (t; __traits(getOverloads, test, "fun"))
        static foreach(attr; __traits(getAttributes, t))
            pragma(msg, attr);

上のコードはこう表示される:

gigi
mimi

for 。 の最後の節は、何らかの意味のある副次的効果なしに値を生成してはならない。 を生成してはならない。これは非推奨メッセージで検出されるようになった。以下の 以下のfor :

// `j`の評価に副作用はない
int j;
for (;; j) {...}

// 不要な再参照
for (ubyte* sp;; *sp++) {...}

// 最初の節はブロック文である
// 最後の節は関数リテラルであり、ブロック文ではない
for({j = 2; int d = 3;} j + d < 7; {j++; d++;}) {...}

注釈:void を返す関数を呼び出すことは、その関数が何もしなくても非推奨ではない。 関数を呼び出すことは非推奨である。これは一般的なコードのためである。

以前は、常にガベージ・コレクターを使って割り当てられていたため、@nogc や-betterC のコードでは利用できなかった。 そのため、以下の回避策が頻繁に使用されていた:

void main() @nogc
{
    int[3] buffer = [10, 20, 30];
    int[] arr = buffer[];
}

これで1行で書けるようになった:

void main() @nogc
{
    scope int[] arr = [10, 20, 30];
}

ただし、以下の制限がある:

• 変数は、推論されるだけでなく、明示的にscope 。scope
• レガシー・コードでメモリ破壊を引き起こさないように、-preview=dip1000 を渡さなければならない。

• 配列リテラルは変数を初期化していなければならない。それ以降の配列リテラルの代入は、依然としてGCを使用する。
• 配列要素はデストラクタを持たない。

これらの制限のいくつかは、将来解除されるかもしれない。

条件がfalseと評価された場合、それ以降の式はすべて文字列に変換され、連結される。 はそれぞれ文字列に変換され、連結される。結果の文字列 がエラー診断とともに出力される。

enum e = 3;
static assert(false, "a = ", e);

表示:

file.d(2): Error: static assert:  a = 3

DIP 1035 - システム変数が承認されたため、@system の変数は@safe コードからアクセスできなくなった。 コードの破損を避けるため、コンパイラーは非推奨の警告から始める。 プレビュー・スイッチはこれをエラーに変えるもので、将来のリリースではデフォルトで有効になる予定である。

@system int* p;

struct S
{
    @system int i;
}

void main() @safe
{
    int x = *p; // `-preview=systemVariables`でエラー、それ以外は非推奨

    S s;
    s.i = 0; // 同上
}

現在のところ、これは明示的に@system とマークされた変数に限定されている。変数のイニシャライザーに基づく@system の推論はまだ実装されていない。

この仕組みは

1. ひとつはtraceinfoの割り当て、もうひとつはtraceinfoの割り当て解除だ。両方とも同じRuntime.traceHandler 関数を介して設定される。デアロケーション関数を設定する2番目のパラメーターはオプションである(そのため、既存のコードは影響を受けない)。
2. Throwable 、トレース情報がまだ設定されていない場合、ランタイムは指定された関数を使用してトレース情報を割り当てる。デアロケーション関数がnullでない場合、関数ポインタはThrowable 、新しいメンバinfoDeallocator にコピーされる。
3. Throwable が破棄されるとき、infoDeallocator メンバが設定されていれば、info メンバ上で呼び出される。

デフォルトのアロケータとデアロケータは、TraceInfo のアロケートとデアロケートにCのmallocとfreeを使うようになった。TraceInfo オブジェクト自体のアロケート以外は、ほとんどすべてがすでにnogcされていた。

利点がある:

1. GCコレクション・ルーチンの内部で実行されたときにスタック・トレースを生成できるようになった。
2. InvalidMemoryOperationErrorがスタック・トレースを持つようになった。
3. あまり知られていないが、@nogc 関数の内部でも、Throwable をスローすると実際に GC を使用していたが、(デフォルトでは)そのようなことはなくなった。
4. 特定のGCハングが修正された(下記のバグ修正を参照)。

欠点として考えられるのは、Throwable がファイナライズされたときにTraceInfo がデアロケートされるため、ポインタがぶら下がる可能性があることである。Throwable からinfo をコピーする場合は、Throwable のライフタイムを超えて保持しないか、infoDeallocator メンバをnullに設定することを確認すること。

新しいfloat およびdouble のオーバーロード std.math.exponential.log, std.math.exponential.log10, std.math.exponential.log1p, std.math.exponential.log2そして std.math.exponential.logb が、対応する精度の適切な「ソフトウェア」実装で Phobos に追加された。 が追加された。さらに std.math.exponential.logbは はpure になった。

この結果、DMDの速度が低下する場合もあるが、GDCとLDCの全体的な高速化率は、 と の両方で3倍以上である。 GDCとLDCの高速化率は、double とfloat の両方で3倍以上である。

これはまた、特に単精度において、より精度の低い結果を意味する、 従って、もしあなたのコードが80ビット中間精度でより正確な結果に依存していたのであれば、今すぐ明示的に引数をキャストしなければならない。 このため、80ビットの中間精度によってより正確な結果を得ようとした場合、引数を明示的にキャストしなければならなくなる。

std.uni からunicode.c またはunicode.Other (大文字と小文字を区別しない) を使用する場合は、コードベースを軽減するか修正する必要がある。

この変更により、Unicode Techical Report #44と一致するようになった。残念ながら、すでに以前の間違った値で使用している場合、これはあなたのコードを壊してしまうので、以下に元の値を反映した関数を示す。

@property auto loadPropertyOriginal(string name)() pure
{
    import std.uni : unicode;

    static if (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;
    }
    else
        return unicode.opDispatch!name;
}

この変更により、コードやプログラムの使用に不具合が生じる可能性がある。 これは、テーブルが大幅に更新されたことと、テーブル・ジェネレータが長年にわたってすべての変更をコミットしていないことなど、いくつかの要因によるものである。

Uniqueがスコープ外に出ると、デストラクタが呼び出されるようになった。 以前はデストラクタは呼ばれなかった。

static int i;

struct S
{
    ~this()
    {
        i++;
    }
}
{
    Unique!S u = new S;
    // S.~thisがここに呼ばれた
}
assert(i == 1);

注釈:上記では、構造体デストラクタは、 のメモリが回収される直前にGCによって呼び出される。 new S によって呼び出される。使用する構造体 デストラクタが、構造体の値に対して再度呼び出された場合に対処できるように注意すること。.init の値に対して再度呼び出されることを処理できるように注意すること。

VisualDパッケージのバージョン は何年も更新されていない。これは、バージョン VisualD の最新リリースである 1.3.1 にバンプされた。

Windows用のNSISインストーラーには、「PATHに追加」というオプションがある。以前は DMDの32ビット版だけがPATH環境変数に追加されていた。現在は Windows 64ビット版では、DMDの64ビット版がPATHから選択される。

これまでdubはビルドアーチファクトをパッケージディレクトリに出力していた。

これにより、依存関係のためにビルドアーティファクトを再利用することができた。 packagesフォルダに大量のビルドアーティファクトが存在する問題が発生した、 パッケージの保存に読み取り専用の場所を使用できない、 ビルドアーティファクトのガベージコレクションが信頼できなくなる。

このバージョンから、ビルドの成果物はデフォルトで $HOME/.dub/cache/build/$BASE_PACKAGE_NAME/$PACKAGE_VERSION/[+$SUB_PACKAGE_NAME] に出力される。 %APPDATA%/cache/build/$BASE_PACKAGE_NAME/$PACKAGE_VERSION/[+$SUB_PACKAGE_NAME] に出力される。

これら2つの関数は、メタデータ・キャッシュ・ファイルへのアクセスをジェネレーターに提供するために使用されていた。 へのアクセスをジェネレーターに提供するために使われていた。これらは決して一般に公開されることを意図したものではない、 JSONファイルフォーマットは安定していなかった。

ビルドキャッシュの導入に伴い、これらを削除する必要があった、 というのも、賢明な移行パスを提供する方法がなかったからだ。 もし使用例があれば、dubリポジトリにissueを開いてほしい。