変更ログ: 2.068.0

問題14828を修正するため、配列の境界チェックとアサートのためのコンパイラー・ヘルパー関数が、モジュールのコンパイル時に一度だけ生成されるようになった。 assert用のコンパイラー・ヘルパー関数は、モジュールのコンパイル時に一度だけ生成されるようになった。 生成されるようになった。このため モジュールを使用する際にリンク・エラーが発生する可能性がある。

もし

undefined reference to '_D5mylib5mymod7__arrayZ'

undefined reference to '_D5mylib5mymod8__assertFiZv'

undefined reference to '_D5mylib5mymod15__unittest_failFiZv'

-profile=gc でコンパイルすると、dmdはGC割り当てを計測し、ランタイムがトレースするようになる。 ランタイムによってトレースされる。ランタイムはトレースを蓄積し、プログラム終了時に プログラム終了時にprofilegc.log 。

例:":

bytes allocated, type, function, file:line
     171        immutable(char)[] example.concat example.d:4
      24        closure D main example.d:18
      16        example.Klass D main example.d:20
            

注釈:core.memoryインターフェイスを使用したGCアロケーションはプロファイルされない。

unittestコードが不要な場合は、コンパイルを高速化するために、中括弧で囲まれたトークンとして解析される。 として解析されるだけである。

unittest { auto r = test(); assert(r); }
// -unittestを指定しないと、unittestブロックのASTは生成されない。

unittest { the contents is just ignored. }
// Since 2.067: れによってパースエラーが発生していた。
//  From 2.068: これと同等なのでエラーは発生しない:
enum unittest_code = q{ the contents is just ignored. };

インライン化をより細かく制御するための新しいプラグマが追加された。 これは-inline スイッチと一緒に使わなければならない。

pragma(inline, true) // 関数がインライン化されていないとエラーになる
int double(int val) { return 2 * val; }

pragma(inline, false) // 決してインライン化されない
int double(int val) { return 2 * val; }

詳しくはドキュメントを読んでほしい。

テンプレート化された関数と同様に、auto return型を持つ関数は常に関数本体を持たなければならない。 関数本体を持たなければならない。コンパイラーはこの事実を利用するように変更された。 コンパイラはこの事実を利用するように変更された。

auto foo()() {} // テンプレート関数
auto bar() {}   // 戻り値の型を持たない非テンプレート関数
void baz() {}   // 戻り値の型を持つ非テンプレート関数

static assert(is(typeof(&foo!()) == void function() pure nothrow @nogc @safe));
static assert(is(typeof(&bar) == void function() pure nothrow @nogc @safe));
static assert(is(typeof(&baz) == void function()));

構文解析の制限が解除され、インデックス付き型タプルの後にドット識別子を付けてtypenameとして使用できるようになった。 型タプルの後にドット識別子を付けてtypenameとして使うことができるようになった。

alias TypeTuple(T...) = T;

struct S
{
    alias T = int;
    alias U = TypeTuple!(long, string);
}

alias Pair = TypeTuple!(S, S);

struct X(Types...)   // タプルのパラメータが使用されている
{

    Types[0].T a;     // Types[0] == S、次にtypeof(a) == S.T == int
    Types[0].U[1] b;  // Types[0].U == S.U、次にtypeof(b) == S.U[1] == string
}
alias x = X!Pair;

IFTIの実行時に、パラメーターのデフォルト引数からテンプレート型を推論できるようになった。 これにより、冗長でエラーの起こりやすいデフォルト型の宣言を避けることができる。

void previously(T=int)(T t = 0) { } // デフォルトの型も指定する必要があった
void now(T)(T t = 0) { } // デフォルトの型は、デフォルト引数のintから推測できる
void main() { previously(); now(); }

無効なリインタープリット・キャストは、バックエンドではなく、コンパイラのフロントエンドで検出されるようになった。 で検出されるようになった。これにより、コンパイル時にリインタープリ キャストをチェックすることができる。 のエラーメッセージが改善された。

pragma(msg, is(typeof({ void* x; auto y = cast(void delegate())x; })));
// Since 2.067: 'true'と表示される
//  From 2.068: 'false'と表示される

void test() { void* x; auto y = cast(void delegate())x; }
// Since 2.067: 内部コンパイラエラー"Error: e2ir: cannot cast ..."を報告するようになった
//  From 2.068: 正しいフロントエンドエラーを報告するようになった。

GCメモリを割り当てていた多くのphobos関数がレンジをサポートするように変更された。 範囲をサポートするように変更された。 レンジを使用することで、GCメモリの割り当てが不要になることが多い。

setExtension("foo.jpg", ".png"); // 新しい文字列を確保する
withExtension("foo.jpg", ".png"); // 確保せずに範囲を返す

GC 2011オプション --DRT-gcopt=profile 。 GCオプションは、最も一般的な操作ごとにグループ化されたAPIコールのプロファイリングを可能にする追加レベル2を受け付けるように拡張された。 プロファイリングできるようになった。

このインスツルメンテーションは、たとえ未使用であっても GC 2011 のパフォーマンスに影響を与えるので、例えば、-debug=PROFILE_API を指定して GC 2011 モジュールを再コンパイルしなければならない。 GCモジュールを-debug=PROFILE_APIで再コンパイルする必要がある。

dmd test.d -O -inline -debug=PROFILE_API -Ipath-to-druntime/src path-to-druntime/src/gc/gc.d
./test --DRT-gcopt=profile:2

    malloc:  9768628 calls, 531 ms
    realloc: 0 calls, 0 ms
    free:    0 calls, 0 ms
    extend:  1100 calls, 0 ms
    other:   826 calls, 0 ms
    lock time: 160 ms
    GC API: 692 ms
GC summary:   12 MB,   52 GC  331 ms, Pauses  227 ms <    4 ms API  692 ms

malloc関数にはGCコレクションの時間が含まれる。ロック時間(GC 同期)は別個に測定され、他の時間には含まれない。 には含まれない。

連想配列のランタイム実装は書き直され、現在では2次プローブによるオープン・アドレッシングを使用している。 オープン・アドレッシングを使用するようになった。 と三角数を使用するようになった。これは古い セパレート・チェイニング の実装よりもはるかにキャッシュに優しくなっており、大きな連想配列のルックアップが~25%高速になる。druntime#1229も参照のこと。

注釈:アロケーションパターンが変化すると(テーブルが大きくなり、ノードが小さくなる。 テーブルが大きくなり、ノードが小さくなった)。 大きなアロケーションを効率的に管理できないからだ。