Rust: 「マクロ1.1」の追跡の問題（RFC＃1681）

何をする必要があるかのチェックリストで問題の説明を更新しました。 網羅的ではない可能性がありますが、うまくいけば、そこまでの道のりの90％が得られるはずです。

わかりました。今日はこれを調べて、どこまで到達できるかを確認します。

cc https://github.com/rust-lang/rust/pull/35957 、実装

＃35957から：librustc_macroクレートの名前をもう少しバイクシェッドする必要があります。 特に、これはすべてのマクロ作成者にとって不可欠なものを含む長寿命のクレートであることが意図されているため、rustc_macro（少なくとも私の考えでは）に制限することは1.1のアイデアについては悪いようです。 以前はこれにlibmacroが必要でしたが、 macroは予約語であるため（将来的にはキーワードとして必要になる可能性があります）、不可能です。 @cgswordsと私は

@nrc ：さて、命名についての私の当面の考え：

• extern crate macros; -短くて甘いですが、マクロを書くためのサポートコードではなく、マクロを含むものとして読み取られる可能性があります
• extern crate macro_runtime; -缶に書かれている通り
• extern crate metarust; -Rustを操作するために、RustについてRustを記述します
• extern crate bikeshed; -手続き型マクロを使用すると、好きな色のRustを使用できます。
• extern crate macrame; -「macromake [r]」のように聞こえます。 おそらく、生のライブラリよりも将来の「素敵な」APIに残したほうがよいでしょう。

@nrcこの質問の重要な側面は、さまざまなマクロスタイルの名前付けです。特に、 libproc_macro場合は、「手続き型マクロ」に懸命に取り組んでいます。用語。 ここでは強い意見はありませんが、専門用語の分野を公然と探求したかどうかはわかりません。

明確にするために、今日のmacro_rulesは単に「マクロ」、つまり「手続き型マクロ」を修飾する必要がある一方で、マクロが意味するデフォルトのことだと思いますか？ それは私にはかなり合理的な計画のように思えます。 そしてその世界では、 libproc_macroはlibmacrosよりも優れていると私は主張します。

ここでの私の考えは、すべてのマクロは「マクロ」であり、実装に基づいて区別する必要がある場合（使用法はすべての種類でまったく同じである必要があります）、「手続き型マクロ」と「例によるマクロ」を使用します。 「構文拡張」と「コンパイラプラグイン」を完全に廃止したいと思います（そしていつか後者を実際のプラグインに再利用します）。

しかし、そうです、私は「手続き型マクロ」という用語を後回しにしたいのです。

@nrc私には理にかなっています！ 「例によるマクロ」は少し扱いに​​くいですが、非常に刺激的で直感的な用語でもあります。 「手続き型マクロ」について私が心配しているのは、「手続き型」はRustでは問題ではないということです。 より直接的なつながりを作る方法があるのだろうか。 「関数マクロ」は正しくありませんが、私が何を意味しているのかを理解できるかもしれません。

ええ、それは完全ではありませんが、Rust以外でよく知られている/使用されている用語であることを考えると、私たち自身の用語を作るよりも良いと思います。 「プログラムマクロ」も可能ですが、私は「手続き型」が好きです。

「手続き型マクロ」に最も近いPerlの用語は、「ソースフィルター」です。これは（特にASTからトークンへの移行に伴い）非常に適切な説明です。

おそらく、「構文トランスフォーマー」または「プログラマティックマクロ」は名前としてうまく機能しますか？ ただし、手続き型マクロには問題はありません。

「手続き型」はすでに人々がこれを呼んでいるものであり、特に「例によるマクロ」とは対照的に、それが何を意味するのかは明確に理解されていると思います。 別の名前を探す心配はありません。

私は、通常使用する「手続き型マクロ」（または「カスタムマクロ」）という用語が好きです。 私は特に_macro_という単語を使用するのが好きです。そうすれば、「通常のマクロ」と同じように（最終的には...）使用できることが明確になります。 このため、「ソースフィルター」は好きではありません（この用語が両方に使用されていることはわかっていますが、フィルターがデータを変換するのではなく、単にドロップすることも期待しています）。

libproc_macroまたはlibmacrosどちらでも問題ありlibproc_macro 。 簡単に回避できるのに、クレート名に_を含めるのが好きではないという理由だけで、後者の方が好きです。 =）

1つの質問：非手続き型マクロから使用できる「サポートルーチン」があると期待することはありますか？ 私はそのような計画を知りませんが、もし私たちがそうし、同じ木枠にそれらを入れたいのであれば、 libmacrosがより良い名前でしょう。 =）

（たとえば、熱心な拡張RFCからの@dhermanのコメントについて少し考えています。）

@nikomatsakis ：関連しているが微妙に異なる質問は、 https：//github.com/rust-lang/rfcs/pull/1561#discussion_r60459479で取り上げたユースケースです-手続き型マクロの実装関数で呼び出すことができるようにしますか？他の手続き型マクロの実装関数？

あるカスタム派生物が別のカスタム派生物を呼び出せるようにしたいことは簡単にわかります。これにより、基本的に、手続き型マクロ定義自体をそのような「サポートルーチン」として使用できるようになります。

しかし、はい、 @ dhermanのgensym例はかなり説得力があると思います。 もちろん、上記の私の質問に対する答えが「はい」の場合、gensymはマクロ（例としてマクロで使用できます）とサポート関数（手続き型マクロで使用できます）の両方です。

貨物PRhttps ：//github.com/rust-lang/cargo/pull/3064があり、チェックリストのすべての「貨物統合」ボックスをチェックする必要があります。

貨物PRについてコメントを残しましたが、異なるタイプの_package_だけでなく、異なるタイプの_dependency_が必要だと思います。 第一に、これは美的にも人間工学的にも優れていると思いますが、それは私の意見です。 しかし、私にも2つの具体的な理由があります。

• 将来、公的部門と私的部門が存在する場合、手続き型部門の公的部門と通常の公的部門が一致する必要がないことを知っておくことが重要です。 例えば
• 将来、インライン手続き型マクロ/準引用符を使用すると、コンパイル時に任意のライブラリを使用できるようになります。
• >手続き型マクロの実装関数が他の手続き型マクロの実装関数を呼び出せるようにしたいですか？

これが示すように、同じクレートは、手続き型マクロの別のクレートの通常の深さ、または別のクレートのマクロの深さである可能性があります。

Serdeは機能しますか？

はいhttps://github.com/serde-rs/serde/releases/tag/v0.8.6

（場合によってはコンテナ属性を除く＃36211）

素晴らしい、@ dtolnayのアップデートに感謝します！

これらのマクロに関するドキュメントはありますか？ それらを使用する唯一の例はserdeであると思います、私は正しいですか？

OK貨物が上陸しました。 それは問題ありませんが、安定化する前にhttps://github.com/rust-lang/rust/issues/35900#issuecomment-243976887に再度

「例によるマクロ」と「手続き型マクロ」は、それぞれ「宣言型マクロ」と「命令型マクロ」としてより適切に分類できると思います。 これは、プログラミング言語のより広く知られている宣言型/
この命名スキームにより、 macro_impクレートとモジュールがmacro_rulesと並列になります。 macro_rulesは、最終的にはより一般的なmacro_decクレートのモジュールになる可能性があります。

@nrc 、「実際のプラグイン」とは、 metacollectやclippyのようなもの、 rustw 、 rustfmt 、 Rust Language Serverのようなもの、またはその他のカテゴリのプログラムを含みますか？

価値があるので、私は「例による」名前をやや嫌います（ $fooパターンは私の心の中で「例」ではないため）。 宣言型と必須型の方が私にはよく聞こえます。

これをいじってみると、1つの問題に気づきました。 Rustが提供する派生物は、コンパイラーが無視することを知っている属性を追加することがあるようです。 このコンテキストは、カスタム派生を通過すると失われます。 カスタム派生として指定された識別関数は何もしないと思いますが、 #[structural_match]属性が追加されるとエラーが発生します。

複製スクリプト

（ demo_pluginという名前のクレート内）

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

#[rustc_macro_derive(Foo)]
pub fn derive_foo(input: TokenStream) -> TokenStream {
    input
}

（別のクレートで）

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

#[derive(PartialEq, Eq, Foo)]
struct Bar {
    a: i32,
    b: i32,
}

#[derive(Eq)]を削除すると、すべてが正常に機能します。

@sgrifああはい、本当に私に思い出させてくれてありがとう！

したがって、ここで起こっていることがいくつかあります。

• #[derive(PartialEq, Eq)]と、コンパイラはPartialEq派生が実際にそのコントラクトを実行することを静的に理解するため、サイレントに#[structural_match]追加します。
• #[rustc_copy_clone_marker]が追加された#[derive(Copy, Clone)] 、同様の属性が発生すると思います。
• 現在、これらの属性のスパンが「内部不安定を許可する」と言っているため、これは機能します。 ただし、解析および再解析すると、スパン情報は失われます。

だから、私たちができるいくつかの解決策：

• 従来、カスタム派生が最初に来ると言います、例えば#[derive(Foo, Eq, PartialEq)]
• これらの属性を省略するには、カスタム派生に依存します
• カスタム派生を検出した場合、カスタム属性を発行しないでください
• コンパイラでまったく異なるメカニズムを使用して、これらの属性が言っていることを伝達しますが、AST自体を介して伝達することはできません。

これらの属性を発行しないか、別のメカニズムを使用することに賛成です。 ただし、 #[derive(Copy, Foo, Clone)]も機能する必要があるため（定義を変更する可能性のあるカスタムコードが途中で実行される場合）、これは非常に注意が必要です。

私が好む行動方針は、カスタム派生を検出した場合にこれらの属性を出力しないことです。 それでも、些細なことではないかもしれません。 今のところ、「カスタムファーストとスタンダードラスト」の慣習で十分ですが、安定させる前にこれを修正する必要があると思います。

免責事項：私はコンパイラの外観しか持っていないので、わからないことがたくさんあります。 ^^

しかし、私が理解していることから、マクロ1.1カスタム派生の現在のアプローチは、一時的な回避策のようなものです。 一時的な回避策は、「かなりの時間」に変換される場合があります。 しかし、長期的には（= macros 2.0）、文字列解析ラウンドトリップは実行されなくなります。これにより、現在、スパン情報が失われます。 ASTのこれらの隠された属性は、マクロ2.0の世界ではそれほど悪いことではなかったのだろうか。 たぶん、コンパイラについてより多くの内部知識を持っている人が言うことができます。 これらの隠された属性がその将来の世界で実際に意味をなすのであれば、従来のカスタム派生を前もって置くことによって回避策をとることを主張したいと思います。 とにかく、すべてはすでに回避策ですよね？

@ colin-kiegel私たちが今していることは将来性がないという意味であなたは正しいと思います。 たとえば、次のようになっているとします。

#[derive(Eq, Foo, PartialEq)]

今日は、 Eq実装を追加し、次にFooのカスタムコードを実行してから、 PartialEq実装を追加します。 構造はEqとPartialEq間で_変更_される可能性があるため、 #[structural_match]によって追加されたEqは、 Foo実行後に実際には正しくない可能性があります。

その意味で、いずれにせよ、必ずしも将来にわたって利用できるとは限らないことに同意します。

私の感じでは、構造の変化に依存するカスタム派生は、それらの隠された属性とは関係なく、一般的にあまりうまく構成されません。 v2.0カスタム派生物はアイテムの構造を変更できますか、それともどういうわけか装飾のみに制限されますか？

ええ、その能力は常にそこにあると私は信じています（TokenStream-> TokenStreamインターフェースに固有です）が、 #[derive]合理的な実装は元の構造の構造を保持すると思います。

構造体が変更されないようにするために、出力トークンストリームに構造体自体が含まれていないことを要求できるとは思いませんか？ 入力構造体TokenStreamは不変のプレフィックスになりますか？ 大きな問題は、ビルドの完了後にプラグインが使用している認識されない属性を確実に無視することです。 おそらく、各＃[derive（）]には接頭辞を付けることができ（たとえば、＃[derive（Foo）]には接頭辞Foo_があります）、理解する属性は最初から始める必要があります。各カスタム派生を処理した後、それらの属性を取り除きますか？

@mystorええ、そのアプローチの問題は認識されない属性です。そのため、構造体全体を入力として使用します。 これは通常、特定のプレフィックス/サフィックス/登録などに依存するよりも柔軟性があります。

v2.0カスタム派生がカスタム属性を_used_としてマークできる場合、残りのアイテムトークンストリームへの_読み取り専用_アクセスに制限される可能性があります。 このようにして、カスタム派生物のより良い構成可能性がIMOに保証される可能性があります。 v2.0マクロでアイテムの構造を変更する必要がある場合は、別のAPIを使用する必要がありますが、カスタム派生は必要ありません。 このように、 #[structural_mach]と（カスタム）派生の順序に関する問題は、マクロ1.1にのみ存在します。 それは理にかなっていますか？

別の問題。 構造体に2つの異なるカスタム派生があり、2番目のものがパニックになった場合、エラースパンは、パニックになったものではなく、最初のものを指します。

複製スクリプト

demo_pluginと呼ばれる木枠で

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

#[rustc_macro_derive(Foo)]
pub fn derive_foo(input: TokenStream) -> TokenStream {
    input
}

#[rustc_macro_derive(Bar)]
pub fn derive_bar(input: TokenStream) -> TokenStream {
    panic!("lolnope");
}

別の木枠で

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

#[derive(Foo, Bar)]
struct Baz {
    a: i32,
    b: i32,
}

Barパニックになった場合でも、エラーはFooを強調表示します。

@sgrifのレポートをありがとう！ この問題の説明を更新しました。マクロ1.1に関連するすべての未解決の問題も追跡したいと思います。

うーん、カスタム派生と#[structural_eq]の相互作用は、私が以前は考えていなかったものです。 それはむしろ私を悩ませます！

トークンストリームにテキストを「追加」する方法があると、1日の終わりに優れたインターフェイスになる可能性があります...スパン情報を保持し、この問題

より一般的なインターフェイスの利点の1つは、パッケージがフィールドに属性を持つことができることです。これは、マクロの実行時に削除できます。 これは、カスタム派生マクロが元のアイテムを変更できるようにするために私が知っている唯一の実際のユースケースです。

インターフェイスの質問は、カスタム派生を「単なる別のマクロ」にするかどうかにかかっていると思います。その場合、他の手続き型マクロ（元のアイテムを変更する場所）と同じインターフェイスを持つことが重要です。 または、それが特別なインターフェースを備えた独自のものである必要があるかどうか。その場合、より制限的な（追加）インターフェースが理にかなっています。

構文拡張には長い間修飾子とデコレータの違いがあり、関係者全員がその違いを本当に嫌っていたと思います。 したがって、カスタム派生を少し特別なものにするという道をたどるのは少し気が進まない（議論された代替案は、ある種の非常に特別なカスタム派生であり、おそらく宣言型の形式でさえある）。

@nrcええと、それでもtokenstream-> tokenstreamである可能性があります。ここでは、最初から開始するnewメソッドを公開していません。

カスタム派生が本当に意味をなすためには、フィールドにカスタム属性を持つことが可能でなければならないことに同意します。 しかし、これを「追加」スタイルで実行できる方法はたくさんあると思います。もちろん、これについては説明する必要があります。 派生マクロがアイテムを変更せず、構成可能であり、さらに#[structural_eq]問題を解決する世界を好むので、私は間違いなく追加スタイルを好みます。 これはちょうどいい量の自由IMOです。

人々がその目的地を気に入らなかったのなら、なぜ以前にこの区別をするのに十分な理由があったので、私は理由を尋ねたいと思いますね。

（私が提案したのは一時的なハックであり、長期的な構成可能性の問題には実際には対処していないと思います。）

私のさまざまなライブラリには現在、 foo!(Bar, parameters...)ようなマクロがあり、パラメーターから構造体Barを生成します。

IRCに関するいくつかの議論の中で、代わりに#[derive(Foo)] #[params] struct Bar;を記述し、 foo!を構造体の本体を生成する#[derive(Foo)]置き換えるというアイデアがありました。

それは明らかに強い議論ではありませんが、構造体が構築されていることがユーザーにとってより明確であるため、私はそのアイデアが本当に好きでした。

代わりに、生成されたimplに配置されるように#[structural_match]を作り直すことができるでしょうか。

（実際には問題を解決しません）

SerdeとDieselの両方がフィールドでカスタム属性を頻繁に使用するため、置換を可能にするためにカスタム派生が確実に必要であることは注目に値します。

ですから、実際、私は#[structural_match]問題についてまっすぐに考えていません。 結局のところ、カスタム派生は何ができるのでしょうか？

• カスタム派生が#[structural_match]属性を誤って挿入した場合、安定性チェックに失敗するはずです。 そうでなければ、それ自体がバグのようです！ （ただし、このコードが機能する複雑で奇抜な方法を考えると、それは私を驚かせません。）
• カスタム派生がそれを削除しても、害はありません。

たくさんの小さなコメントを書いて声を出して考えて申し訳ありませんが、もう1つの懸念があります。 カスタム派生は#[structural_match]アノテーションを「改ざん」できない場合がありますが（「マジックスパン」がないと終了するため）、既存のアノテーションのスパンを台無しにしてしまう可能性があります。派生は正しい順序で適用されますが、これは残念なことです。 基本的に、@ colin-kiegelが話している非構成可能性のインスタンスですが、飛行中の構造体を変更する試みはありません。

（つまり、安定したものを使用できるかどうかを判断するのはスパンに依存しているため、スパン情報を失うと、そこでいくつかの厄介な問題が発生する可能性があります。）

編集：わかりました、読み返してみると、 再導出したことが

また、不安定な実装の詳細を安定したコードに公開していることを意味するため、これはやや粗雑です。 理想的には、安定したコードは#[structural_match]アノテーションが存在することさえ知らないでしょう。

@nikomatsakisよく、

@ colin-kiegel

派生マクロがアイテムを変更せず、構成可能であり、さらに＃[structural_eq]の問題を解決する世界を好むので、私は間違いなく追加スタイルを好みます。 これはちょうどいい量の自由IMOです。

もちろん、構成可能性の条件は異なりますが、マクロの変更は構成可能である可能性があると思います。 コンパイラーまたは慣例によって強制される、派生の操作に関する一連の事前条件と事後条件が明確に存在する必要があります。 非突然変異は、ここで選択する可能性のある不変条件のスペクトルの1つの極端なように思われます。すでに、それを和らげることができる方法（たとえば、使用される属性のマーキング）について説明していることに注意してください。 一般的には、最も単純な条件を好み、コンパイラーによってそれらを強制することをお勧めします。 ただし、これは、特別にカスタム派生をどのように処理する必要があるかという問題にある程度含まれています。

人々がその目的地を気に入らなかったのなら、なぜ以前にこの区別をするのに十分な理由があったので、私は理由を尋ねたいと思いますね。

当時は強いモチベーションがあったとは思いません。 実装は簡単で、「良いアイデアのように思えた」と思います。 実装がより複雑になり、通常は無関係なマクロ作成者の区別が追加され、変更するか装飾するかを選択する必要があるため、マクロの柔軟性が低下するため、嫌われています。

カスタムデリバティブの長期的な設計を検討し、正しい方向に向かっていることを確認したいと思います。 1.1ソリューションの制約と、できるだけ早くやりたいという願望がここの水を濁らせており、私たちはより大きなビジョンを見失っているように思えます。

何らかの方法でカスタム属性をサポートすることは難しい要件のように思われるという点で、 @ jimmycuadraに同意します。 @nikomatsakisも正しいですが、現在の#[derive(PartialEq, Eq)]扱いは標準以下であり、安定させるべきではありません。 最後に、 @ mystorには、カスタム派生モードがこの魔法の属性についてさえ知らないはずであるという非常に良い点があります。 将来的にはさらに追加したいと思うはずですが、マクロ1.1でそれができないようにしたくありません。

また、カスタム派生の長期設計に関する@nrcの感情を反映して、これの多くは#[derive]実際にどのように機能するかに要約されると思います。 任意の属性をサポートする場合、 @ nrcは修飾子のみを持ち、デコレータを持たないことについては良い点があると思いますが、 #[derive]は、カスタム派生が新しい属性を定義するのではなく、単にそれに取り組むという点で非常に特別です。既存のもの。

現在、実装には#[derive]モードの厳密な左から右への拡張があります。 すべての内部派生モードはループで展開され、カスタム派生モードがヒットするたびに、再シリアル化して展開し、ステージ1に戻ります。これは、コンパイラが#[derive]属性を1回に複数回実行できることを意味します。タイプdefinition_。 それは毛むくじゃらの束につながります。

私が持っているかもしれない1つの提案は#[derive]の拡張順序を微調整することです：

• まず、マクロ1.1からのすべてのカスタム派生属性が1つずつ展開されます。 つまり、 #[derive(Clone, Foo)]がある場合、最初にFoo導出します。ここで、構造体には#[derive(Clone)]アノテーションがあります。 その#[derive]持続する場合は、カスタムの組み込み特性Clone導出します。
• 次に、コンパイラが不明なすべての派生属性が#[derive_Bar]属性に展開されます。 これは、ある時点で削除する必要がある下位互換性のハックであり、属性を拡張するために使用される方法です。
• 最後に、コンパイラはすべての既知の組み込み#[derive]属性を拡張します

これには、左から右に拡張していないという驚くべき効果がありますが、これは#[derive]しかないことをもう一度覚えておいてください。 これにより、コンパイラーは構造体定義について最大限の知識を得ることができ、組み込みの特性を拡張するときに、型の構造が変更されることはないことがわかります。

それはどのように聞こえますか？ 私はそれがここですべての制約を解決すると信じていますか？

@nikomatsakis impl属性を配置する戦略が機能するかどうかはわかりません。これは、他のカスタム派生モードによって、理論的には構造体のレイアウト、さらにはフィールドのタイプが変更される可能性があるためです。 これは、最初に拡張されたときのコンパイラの仮定に違反すると思います。

派生物が処理される順序は、Rust参照などを介して、左から右へと公式に宣言されたことがありますか？ より一般的には、属性の順序は重要ですか？ それがそのように実装されたのは偶然のように思えます、そしてマクロの作者は左から右の順序に頼るべきではありませんでした。 カスタムを処理するというAlexの提案は、コンパイラによって追加された魔法の属性が決して見られないように、最初に導き出されます。

カスタム派生が構造体のレイアウトを変更する可能性があるという考えが気に入らないことを付け加えたいと思います。 安全に配慮したものに使えるようにしたいと思います。 例として、 rust-gcによって使用される#[derive(Trace)]実装について考えてみます。

#[derive(Trace)]
struct Foo {
    a: Gc<i32>,
}

展開先：

struct Foo {
    a: Gc<i32>,
}

unsafe impl Trace { // NOTE: Strawman impl
    unsafe fn trace(&self) { Trace::trace(&self.a) }
}

ただし、構造体のフィールドの変更を許可する場合は、 Evilカスタム派生を定義できます。

#[derive(Evil)]
struct Foo {
    a: Gc<i32>,
}

展開先：

struct Foo {
    a: Gc<i32>,
    b: Gc<i32>,
}

それらを組み合わせると、次のようになります。

#[derive(Trace, Evil)]
struct Foo {
    a: Gc<i32>,
}

展開先：

struct Foo {
    a: Gc<i32>,
    b: Gc<i32>,
}

unsafe impl Trace {
    unsafe fn trace(&self) { Trace::trace(&self.a) }
}

これはTrace不健全な実装です。 rust-gcと一緒に使用すると、 bがぶら下がっている参照になる可能性があり、これはひどく安全でなく、健全ではありません。 これは、 Traceがタイプで#[derive]にとって安全なものではなくなったことを意味しますが、これは非常に残念なことです。

私は個人的に、行儀の良い#[derive]は構造のレイアウト/構成を変更しないと感じています。変更する場合は、運が悪いだけです。 カスタム派生が属性を削除する機能は重要であり、それをあきらめることは初心者ではありません。 さらに、何らかの形のホワイトリストを含む他の実装は、現在の単純なインターフェイスとは大きく異なります。

言い換えれば、 #[derive]が構造体を変更しないという「純粋さ」は、コストに見合う価値があるとは思いません。

フィールドを追加または削除せずに属性を削除する方法があるのだろうか（たとえば、再解析された構造体のフィールドが元の構造体と同じであることを確認し、そうでない場合はエラーが発生する） t、ただし他のものが変更されても文句はありません）。

派生に構造体の変更を許可することについて、私は悪い気持ちを持っています。 @mystorの例は、私が構成可能性について高レベルで話していたときに私が念頭に置いていたものです（

利用可能であれば、人々はこれを悪用すると思います。 そして、これにより、消費者はカスタム派生実装の詳細とその実行順序について推論する必要があります。

「ねえ、これが何をするのかわからないが、他のものは理解している」と言えば、相互依存関係はありません。 そうでなければ、それはつま先の痛みになり、私はそれが起こると信じています。

悪意のあることを行う手続き型マクロは、悪意のあることを行うために使用するクレートとは本当に異なりますか？ どのクレートにも、安全でないコードが含まれている可能性があります。 このケースは、コミュニティの評判、ソースの自分での検査など、自分で作成していないコードの信頼性を判断する方法に関係しているようです。

クレートが悪意のあることをしようとは思わない。むしろ、クレートが「賢く」、実装をより効率的にするため、またはできるため、他のカスタム派生実装を壊すために巧妙なトリックを行うことを期待している。 一部のカスタム派生物が、実装でのみ使用される構造体にフィールドを追加し始め、それらがトレースのようなものを壊してしまう場合でも、私はそれほど驚かないでしょう。

@mystor理論的には関連性があるように聞こえますが、実際にはRustで構造体のすべてのフィールドを提供する必要があるため、たとえばC ++よりもそのようにサイレントに動作する可能性ははるかに低くなります。

@alexcrichton

私が持っているかもしれない1つの提案は#[derive]拡張順序を微調整することです

私はこの考えが好きです。 おそらく、ドキュメントの観点から述べることは、単に拡張の順序が「未定義」であるということです。 最近、PartialEq / Eqを拡張しましたが、厳密な理由はありません。

構造体の定義を変更する派生物については、微妙に聞こえるかもしれませんが、それほど気になりません。 また、「自動挿入」フィールドは非常に便利だと思いますが、主に人々に順序に依存させたくないため、このような修飾子は派生リストに入れるのではなく、個別の属性にすることをお勧めします。ちょうど今拡張の。

PS。 クレートハッシュなどでシードされた（決定論的）RNGを使用して、ユーザーのカスタム派生の展開を並べ替えることを真剣に検討します。これにより、ユーザーは展開順序に依存できなくなります。 暗黙の依存関係を防ぐために、私は常に何らかのコンテキストでこれを実行したいと思っていましたが、チャンスはありませんでした。 ;）

編集：気が変わったので、構造体の

したがって、私の理解では、カスタム#[derive]が構造体を変更できるようにするための引数は次のとおりです。

• 場合によっては役立つかもしれません（例は見ていませんが、存在すると思います）
• 使用後の属性を削除できるようにしたい
• カスタム派生作者により多くの力を与える

カスタム#[derive]実装に制限を追加するための引数（構造体の名前と構造体のフィールド/フィールドの名前を同じままにする必要があるなど）は次のとおりです。

• これにより、カスタム#[derive]によって生成されたコードは、健全性のために派生しているタイプの構造に依存できます（たとえば、実際のバッキングタイプを確認する必要があるrust-gcからの#[derive(Trace)] 、または、それは健全ではなく、潜在的には解放後の微妙な使用方法です）
• 構造体を介してマクロ展開間で伝達される情報が少ないため、マクロ展開での暗黙的な依存関係の可能性が低くなります。

私の意見では、 unsafe trait implsまたは安全でないコードに依存するコードを生成する健全なカスタム派生実装を作成する機能は非常に重要であり、最初のセクションの機能のほとんどを達成する方法があると思います（安全な方法で構造体フィールドを追加する機能を除いて）。 なんらかの制約がなければ、rust-gcのようなクレートを安全に実装できるとは思いません。 私には2つのアイデアがあります：

アイデア1

カスタム派生パスを実行する前に、構造体の名前と各フィールドの名前を読み取ります。 パスが完了し、構造体が再解析されたら、構造体の名前が同じであるかどうか、および各フィールドの名前（およびフィールドの数）が同じであるかどうかを確認します。 そうでない場合は、エラーを発生させてビルドを強制終了します。

これにより、カスタム派生プラグインが依存すると予想される基本的な構造プロパティが壊れないことが保証され、より多くの健全なカスタム派生プラグインがあることを意味します。 これには、現在のアプローチとの下位互換性があるという利点もあるため、将来的にそれが好きだと判断した場合は、切り替えて誰のコードも壊すことができません。 また、今日と同じように、未使用の属性の場合も処理します。

アイデア2

すべてのカスタム派生プラグインに同じ入力TokenStream（プログラムで記述された元のテキスト）を与えます。 結果が再解析されるときに、出力構造体にまだ存在する属性を記録します。 すべての出力トークンストリームに属性が存在する場合は、未使用の属性について文句を言います。

これは、順序の依存関係を持つことが不可能であることを意味し（概念的には、すべてのカスタム派生プラグインは同じ元のオブジェクトから機能します）、プラグインの構造を台無しにすることも不可能になります。 すべてのカスタム派生がほぼ正常な方法で動作し、既存の構造体に基づいて新しいアイテムを生成するだけであるため、このアイデアが気に入っています。 これは、現在のソリューションを変換できるソリューションに変換するのも簡単です。

TL; DR

要約すると、構造体の変更を許可することの特定の利点と、それが安全な#[derive(Trace)]や常に正しい#[derive(Serialize)]などを可能にするという安全上の懸念を上回る理由を理解したいと思います。 構造体の変更ルートをたどってしまう場合は、正当な理由があると確信していますが、Traceカスタム派生の名前を#[derive(unsafe_Trace)]に変更するのは非常に悲しいことです。

@alexcrichtonのソリューションは良いトレードオフだと思います。 一部のカスタム派生が行う変更は、デフォルトの変更が適用されることを間違いなく期待します。

@mystorには、不快な驚きにつながる可能性があるという良い点がありますが、 structを変更する可能性があることは必須のようです。 一方、手続き型マクロのユースケースを組み合わせたクレート、安全でないコード、およびセキュリティ上の懸念は、かなり珍しいようです。

オフトピック：この実装は、マクロがエラーを適切に報告する方法を提供しますか？

カスタム派生の展開順序をランダム化する@nikomatsakisのアイデアが好きです。 それは間違いなく「悪い」習慣があまりにも人気になるのを防ぐのに役立ちます-そしてそれをするのにあまり努力するべきではありません。

@mystorの3番目のオプションは、すべての派生が適用された後、これらの安全性チェックを1回だけ実行することです。 これは100％健全ではありませんが（2つの派生が同じフィールドを追加および削除する可能性があります）、ヒューリスティックな対策の観点から、カスタム派生で構造体定義を変更しようとする試みを最初から防ぐだけで十分です。

構造体の変更に関する懸念は実際には見られません。 フィールドを目に見えない形で追加することはできません。初期化中に何か注意する必要があります。 それが起こっていることを_本当に_心配している場合は、派生物を記述して、構造体全体が簡単に表示されない場合にコンパイルに失敗するコードを生成できます。

@sgrifは、おそらくほとんどの場合に当てはまりますが、デフォルトの特性または同等のものを導出して使用する場合はそれほどではありません。

@sgrif PS：ほとんどの錆の作者はおそらく自分のコードで何が起こっているのかを理解しているので、意図的にそのようなマクロを使用することを選択した場合、構造体の変更に驚かないかもしれません。

構造体にマクロを適用する一般的な使用例は、確かに構造体の変更と装飾の_組み合わせ_です。 しかし、一般的な比率は「装飾が多く」、「変更が少ない」と予想しています。 ここで明確に分離することは、読みやすさと柔軟性を向上させるので良いことです。

• 柔軟性：2つのカスタム派生物を適用したいとします。どちらも両方を実行します。つまり、変更と装飾を行います。 どのように注文しても、希望する結果が得られない場合があります。 ただし、変更が別のメカニズムを介して行われ、装飾がすべて後で適用される場合は、複数の変更と装飾をより制御可能な方法で組み合わせる柔軟性があります。
• 読みやすさ：他の誰かのコードを読んでいて、構造体に10個の派生が適用されていて、そのうちの1つが構造を変更している場合、それを理解するのにもっと時間が必要になります。

したがって、 @ mystorの議論のこの部分は説得力があると思いますが、次のようになります。

カスタム＃[derive]によって生成されたコードは、健全性のために派生しているタイプの構造に依存することができます（たとえば、実際のバッキングタイプを確認する必要があるrust-gcからの＃[derive（Trace）]、またはそれは不健全であり、潜在的には解放後の微妙な使用方法です）

派生でこれを強制しようとすることは、物事を進めるための間違った方法かもしれないと思います。 具体的には、我々は、おそらく一般的な場合の構成定義を変更する機能をしたいです（はい、それは透明ではないだろうが、だから何）。 つまり、後で構造体が変更されないことを保証できる「サウンド」 Traceを使用するというアイデアは、何らかの方法で解決する必要があるかもしれません。 デコレータが下から上に適用されるかどうかを検討します。

#[mangle] // <-- custom decorator that does bad things to struct definition
#[derive(Trace)]
struct Foo {
    x: T, y: U
}

Trace implは、 struct定義が変更された場合に_it_がコンパイルに失敗するように記述できると考えられるかもしれません。 例えば：

unsafe impl Trace for Foo {
    fn trace(&self) {
        let &Foo { ref x, ref y } = self;
        <T as Trace>::trace(x);
        <U as Trace>::trace(y);
    }
}

ただし、 #[mangle]が本当に悪魔的なものである場合は、implをねじ込むこともできます。 =）ここでできることはたくさんあります。

これらの会話のオブザーバーとして、 #[derive]はimplブロックを追加し、兄弟アノテーションを導入することのみが許可されるという公式または非公式のルールを持っていることを嬉しく思います（ #[mangle(Foo, Bar)]サウンド型の構造を_変更_することに専念している😸）。 #[mangle]は、定義された評価順序を

注釈の間にまだ定義されていない場合は、おそらく評価順序を定義する必要があります。

これについての私の意見はリラックスしたと思います。 @nikomatsakisは、＃[ let Foo{ ... }トリックは、適切な場合にレイアウトが正しいことを確認するために機能するようです。 ただし、誰もが独自に発見する必要がないように、おそらくどこかに文書化する必要があります。

@nikomatsakis

• mh .. _derive_の前にカスタムデコレータを適用する必要があるという追加のルールがある可能性があります。さらに、_derivesはitem_を変更できません。 これにより、一般的に派生メカニズムを強化/精製することができます。

しかし、後の変更に対してカスタム派生を_個別に_強化する別の方法があることも嬉しく思います。 :-)

属性が適用されるアイテムの内部を変更する必要がある場合について、 u.r-l.oで「Qtwith Rustの実装前フィードバック」スレッドに出くわし、次の投稿を行いました。

https://users.rust-lang.org/t/pre-implementation-feedback-for-qt-with-rust/7300/19

注目すべき点の1つは、ここでは、構造体ではなく#[derive] （または同様のもの）を_trait_に適用することを提案しています。その中に追加されるアイテムはconst特性メソッドになります。

私が上で提起した貨物の問題と同様に、私は

#[macro_use]
extern crate double;

doubleというクレートから手続き型マクロをインポートします。 コンパイル時に（実際のRuestのように）ランタイムコードを使用しているため、Racketの(require (for-syntax ...))類似したフェーズインクリメントのインポートステートメントが必要です。 [ラケットのドキュメントはhttps://docs.racket-lang.org/reference/require.html#％28form ._％28％28lib._racket％2Fprivate％2Fbase..rkt％29._for-meta％29％29、残念ながら、正しいセクションをリンクする方法がわかりません。]

ブログ投稿http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/は、Template Haskellで行われたフェーズの間違いを指摘しており、興味深いかもしれません- --Rustで同じ過ちを犯したくありません。

@ Ericson2314 Rustの違いは、 doubleが_特定のフェーズ用に_すでにコンパイルされていることです。
つまり、クレートは、たとえばmacro_rules定義されているかのように、マクロ/修飾子インターフェイスのみをエクスポートします。
手続き型マクロとその下にあるRustアイテム（手続き型マクロを形成する）の両方をエクスポートするクレートを作成できることは興味深いことですが、これまでのところ、どのような形でも提案されていないようです。

構築中のクレートが何をどのようにエクスポートするかについて多くのことを選択できるようにすることは理にかなっているかもしれませんが、異なるコンパイルモデルでLISPからシステムを卸売りするだけでは逆効果に思えます。

ええ@eddyb私はこの「作成はそれがダウンストリームでどのように使用されるかを知っている」方法論に懐疑的です。 私たちのコンパイルモデルのために、Racketよりもフェーズが重要である場合（Racketがクロスコンパイルできるかどうかさえわかりません）、最後の議論は得られません。

安定化計画に関するlangチームディスカッションにノミネートされました。

Serde側では、既存のコンパイラプラグインのサポートを停止し、すべての夜間ユーザーにMacros 1.1を公式に推奨する前の残りの問題の短いリストを次に示します： https ： Rustから必要なのは、＃36211を修正することだけです。 私たちが急速に進歩している他のすべて。

syntexを使用せずにrustc_macroを実装するPRを開いているので、コンパイル時間の心配をやめることができますhttps://github.com/serde-rs/serde/pull/548。

編集：気にしないでください、＃36211は古いsyntexの実装にのみ影響しました

私は金曜日までにディーゼルポートを完成させようとします。そうすれば、これで必要なすべてが実行されることを確認できます。

@dtolnayにserde-rs / serde＃548が与えられましたが、serdeのブロッカーは残っていますか？

@sgrif素晴らしい、ありがとう！ それを行ったら（または以前に）、遭遇した残りのブロッカーについてここにコメントできますか？

はい、そうします。

火、2016年9月27日には、午前7時29分PMアレックス・クライトン[email protected]
書きました：

@dtolnayhttps ：//github.com/dtolnay指定されたserde-rs / serde＃548
https://github.com/serde-rs/serde/pull/548 、残っているものはありますか
Serdeのブロッカー？

@sgrif https://github.com/sgrif素晴らしい、ありがとう！ あなたがそれをしたら
（または以前）あなたが持っている残りのブロッカーでここにコメントできますか
遭遇しましたか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/35900#issuecomment -250028743、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABdWK7MnA1rpn-WGji8gwAT2JCIqB4LFks5quaa-gaJpZM4JqEAX
。

@alexcrichton

serde-rs / serde＃548が与えられた場合、serdeのブロッカーは残っていますか？

いいえ、@ oli-obkまたは@ericktが今日または明日そのPRをレビューした場合、翌日すべてをプッシュして、Rusotoのような少数の著名なユーザーを移行できます。

@dtolnay私はRumaでserde_macrosを多用しており、もっと目を必要とする場合は、serde_deriveのテストも支援したいと思います。

実際、私もdiesel_codegenを使用しているので、Rumaはこれら両方のライブラリのMacros1.1バージョンの優れたテストの場です。

Serde 0.8.10をリリースし、serde_macrosが廃止されてMacros1.1が採用されることを発表しました。

「cargodocworks」のチェックボックスを追加しましょう-https ：//github.com/rust-lang/cargo/issues/3132。

@dtolnay完了！

これらがserde_deriveのバグなのか、rustc / rustdocのバグなのかはわかりませんが、生成されたドキュメントに2つの問題があることに気づいています。

• リテラル「///」は、カスタム派生を使用するタイプの生成されたdocstringの先頭に表示されます。
• DeserializeとSerializeは、カスタム派生を使用するタイプの「トレイトの実装」セクションには表示されません。

リテラル「///」は、カスタム派生を使用するタイプの生成されたdocstringの先頭に表示されます。

これはsynバグでした。 修正を加えて0.8.2をリリースしたので、 cargo updateで入手できます。

2つ目についてはわかりませんが、@ alexcrichtonにお任せします。

@jimmycuadra

• DeserializeとSerializeは、カスタム派生を使用するタイプの「トレイトの実装」セクションには表示されません。

それはかなり怪しいですね！ これはrustdocのバグのようですが、おそらく新しいバグではありません。 たとえば、rustdocはCopy実装ではこれを示していません。

#[derive(Clone)]           
pub struct Point {         
    x: i32,                
    y: i32,                
}                          

const _FOO: () = {         
    impl Copy for Point {} 
    ()                     
};                         

そのパターンは、implを生成するためにserde-deriveによって使用されます。 @dtolnay serde_macrosにも同じ形式の世代がありましたか？ ドキュメントの問題を解決するために、今のところ離れるのは簡単でしょうか？

@jimmycuadraは、それに関するrustdocの問題を追跡するために、別のバグを開きたいですか？

@dtolnay serde_macrosにも同じ形式の生成がありましたか？

はい。

ドキュメントの問題を解決するために、今のところ離れるのは簡単でしょうか？

いいえ。私が知る限り、これがこれらの制約の両方を満たす唯一のソリューションです。

• クレートルートにない、つまり::serdeではないserdeをサポートする必要があります。 これは、別のモジュールの機能フラグの後ろにserdeimplを配置する場合によく見られます。
• 周囲のモジュールからプライベートタイプを使用できる必要があります。

詳細については、 https：//github.com/serde-rs/serde/issues/159を参照してください。

@dtolnayああ、わかりました、明確にするために、

更新：ポートは完全には完了していませんが、ほぼ完了しています。 私がすでに報告したこと、または私たちが遭遇することがわかっていた小さな制限以外の問題はありません。 「ディーゼルワークス」ボックスをチェックするのはおそらく安全です。今夜行われない場合は、明日Macros1.1でリリースされる予定です。

それに続く人々のために、私は＃36945を開いてrustc_macroをproc_macroに名前を変更しました。これは、このクレートの名前に関するコンセンサスのようです。

rustdocに欠落している特性の実装（現在、別の問題で追跡されています）は、マクロ1.1に固有ではないようです。 無視しても安全です。

mockersライブラリをコンパイラプラグインからマクロ1.1に移植しようとしましたが、「エラー：カスタム派生属性は構造体/列挙型アイテムにのみ適用できます」というメッセージが表示されました。 コンパイラプラグインを使用すると、特性に「派生」を使用することができます（多少奇妙ですが）。 私はここで運が悪いのですか？

@kriomantおもしろい！ #[derive]をトレイトに適用できるようにすることを意図していたかどうかわからないため、これは実際には今日のカスタム派生のバグである可能性があると思います...

今のところ保守的であると思いますが、まだ特性上の派生を_安定化_しない可能性がありますが、おそらく不安定な機能を追加することができます。 @ rust-lang / lang？

@alexcrichton custom_deriveの観点から、トレイトと構造体の違いは何ですか？

@KalitaAlexeyなし、実際のderive実装に一致人為的な制限です

@alexcrichtonトレイトへのサポートを拡張できますか？

上で

私は個人的に、派生オントレイトを追加したくありません。それは、それ自体を派生させるのではなく、カスタム属性テリトリーの線に沿っているように見えるからです。 （例えば、最初に作成された#[derive]の精神に反します）

カスタム派生は、通常の派生とまったく同じルールに従うことをお勧めします。 後で変更したいと思うかもしれませんが、RFCを使用する必要があると思います（私もかなり冷静ですが、説得力のあるユースケースとさまざまなエッジケースの適切な処理によって私の考えを変えることができます）。

@alexcrichton

今のところ保守的であると思いますが、まだ特性上の派生を安定させることはできないでしょうが、おそらくそれに不安定な機能を追加することができます。 @ rust-lang / lang？

👍私から。

わかりました、不安定な機能は良いですが、それは私のライブラリがまだ安定して動作しないことを意味します（コード生成なしで）。 また、 macro!(…)構文は「マクロ1.1」でもカバーされていませんが、正しいですか？

私はprocマクロRFCを再検討していますが、マクロクレートは自分自身を#[cfg(macro)]宣言する必要があるという計画がありました。 マクロ1.1にはこれは必要ありませんが、特別なクレートタイプが必要です。 2つのメカニズムはやや直交しています。1つ目はコンパイルのフェーズを表し、2つ目はクレートの種類を表します。 しかし、それらは多少重複しています-後者は前者を意味します。 前者は、同じクレートでprocマクロと非マクロ関数を宣言するように拡張されますが、後者はそうではありません。

ここで何かを変更する必要があるかどうかはわかりません。おそらく、procマクロの提案を下位互換性にハックする可能性があります（マクロをロードするメカニズム、つまりクレートタイプの説明を意図的に省略しています）。 しかし、安定期の間に熟考する何か。

@kriomant正解、ええ

@nrcは現在、実際にはcfg(rustc_macro)として定義されています（まもなくproc_macroに変更されます）。 必須ではありませんが、クレートへのリンクのコンパイル時と実行時の両方の概念に必要になると思いましたか？ つまり、proc-macroクレートを2回コンパイルします。1回はクレートタイプproc-macro 、もう1回はクレートタイプrlibで、後者はlibsyntaxなどにリンクしません。それ。

今のところ、それを_必要としない_のは問題ないようですが、後日、ランタイムサポートにオプトインする必要があると思いますか？ （クレートを2回コンパイルする）

@alexcrichton #[proc_macro_derive]はそれを意味するでしょうか？ 同じように#[test] #[cfg(test)]意味します。
（今すぐ追加する必要があるという意味ではありません。 cfgを追加した場合の最悪のケースは、未使用のアイテムの警告です。）

@eddyb extern crate proc_macro;どうですか？ それらも壊れそうな気がします。

@mystorこれは、タイプと実装がたくさんある通常のクレートです。

ただし、 libsyntaxにもリンクしていません。つまり、クレートがproc_macroクレートを使用していて、クロスコンパイルしたい場合は、構文もクロスコンパイルする必要がありますか？

@eddyb yes #[proc_macro_derive]は自動的に無視される可能性がありますが、問題は、これらの関数が推移的に到達するすべてのもの（ extern crate proc_macro ）を無視する必要があることです。 これは「単なるクレート」ですが、実行時に重大な影響があります（動的リンク、クロスコンパイルされたターゲットでは使用できないなど）。

テストには#[cfg(test)]があることに注意してください。したがって、基本的に同じ目的で#[cfg(proc_macro)]を提供することは私には合理的と思われます。

@alexcrichton _Ideally_、クレートにはエクスポートされたものしかなく、ダイナミックリンクなどは必要ありません。 libstdです。 ただし、 #![no_std]場合に問題が発生することがわかりました。

すべてをキャッチしたい場合は、最初からダブルコンパイルを実行する必要があるようです：失望：。

編集：待って、私も何を考えていますか？ カスタムクレートタイプが必要です。二重コンパイルは、手続き型マクロ/属性/派生物などをエクスポートする通常のクレートに適用されます。 したがって、今のところ関係ありません。
ただし、少なくとも、新しいクレートタイプに常に設定される#[cfg(proc_macro)]を導入することはできます。

🔔この機能は、このリリースサイクルの終わりに安定することを目的として、最終コメント期間に入ります！ 🔔

現在、安定化を検討する理由は次のとおりです。

• この機能のAPIサーフェスは、設計上、_非常に_保守的です。 同時に、手続き型マクロの事実上の計画と上位互換性があります
• この機能はSerde、そして間もなくDieselを通じて急速に普及しつつありますが、特に、普及しているのは主にカスタム派生の_クライアント_としてです。
• FCPに入ると、機能が実際に安定して出荷されるまでに3か月かかります。これは、残りの問題を見つけるのに十分な時間です。

このスレッドに関する以前のコンセンサスに基づいて、名前がproc_macroにシフトしていることに注意してください。 このリリースサイクルの残りの間、これと他の細かい点をバイクシェッドし続けることができます。

クレートを2回コンパイルすると、非常に粗雑に聞こえます。スコープは正しく機能しません。 本当にextern! crate needed_for_my_inline_proc_macros;ようなものははるかに優れたソリューションです。

@aturonなに、人々はこの数日前に使い始めたのではないですか？

@ Ericson2314それより少し長いですが、FCPのコメントで説明されているように、安定したチャネルに出荷されるまでの_最小_時間は今から3か月であり、この非常に狭いインターフェイスには十分すぎると感じています。

FCP自体は6週間の長さの事件であり、必ずしも安定化への道を歩むことを意味するわけではないことに注意してください。 ただし、少なくとも今すぐプロセスを開始することで、それまでに問題が発見されなかったと仮定して、この機能を3か月で出荷する機会を作成します。

ああ、わかりました。 私は3か月の部分を思い出しましたが、それらの3つの口の中のFCPの位置を忘れました---それは8月22日から3つの山だったのでなければ。その時のタイミングを気にしないでください。

私が提起したフェーズの問題は、procマクロの話のこの小さな部分にも影響を与えると思うので、それらに対処してもらいたいと思います。

@alexcrichton rustc_copy_clone_markerと他のrustc_attrsはまだ私たちを噛んでいます。 https://github.com/serde-rs/serde/issues/577を参照して

#[derive(Copy, Clone)]
#[cfg_attr(feature = "serialize", derive(Serialize, Deserialize))]
pub struct MyStruct {
    value: i64,
}

回避策は順序を入れ替えることですが、これが修正可能かどうかを確認することにしました。

#[cfg_attr(feature = "serialize", derive(Serialize, Deserialize))]
#[derive(Copy, Clone)]
pub struct MyStruct {
    value: i64,
}

https://github.com/sfackler/rust-postgres-deriveをマクロ1.1に移植し終えました。比較的苦痛はありませんでしたが、複数の派生によって読み取られる属性の処理は非常に苦痛です。 Serdeは同じ問題に遭遇しましたが、両方の派生物を同時に展開するには、一連の奇妙なロジックが必要です： https ：

安定化を妨げるべきではありませんが、著者側では比較的大きな人間工学的問題であり、おそらくすぐに取り組む必要があると思います。

私はquote 0.3.0をmacro_rules!スタイルの繰り返しをサポートしました（ @nrcに微調整をありがとう）。 準/シンテックスなしでprocマクロを開発している場合は、おそらくこれが必要です。 postgres-deriveからの使用例：

pub fn enum_body(name: &str, variants: &[Variant]) -> Tokens {
    let num_variants = variants.len();
    let variant_names = variants.iter().map(|v| &v.name);

    quote! {
        if type_.name() != #name {
            return false;
        }

        match *type_.kind() {
            ::postgres::types::Kind::Enum(ref variants) => {
                if variants.len() != #num_variants {
                    return false;
                }

                variants.iter().all(|v| {
                    match &**v {
                        #(                           // \
                            #variant_names => true,  //  |----- new feature
                        )*                           // /
                        _ => false,
                    }
                })
            }
            _ => false,
        }
    }
}

興味があります。なぜ#ではなく$ですか？

編集：引用構文は${...}なると常に思っていましたが、数年経ってもES6テンプレートリテラルに執着しすぎている可能性があります。 \{...}も機能しますが、他の場所でも役立ちます。
角かっこは見つけにくいようですが、心配する必要はありません。

興味があります。なぜ#ではなく$ですか？

それはmacro_rulesマクロであり、私がやりたいことは何もできないからです： smile:。 $vは単一のトークンとして照合され、 $vから変数vを使用する方法はありません。 対照的に、 #vは2つのトークンであるため、別々に照合してIDを使用して処理を行うことができます。

macro_rules! demo {
    ($tt:tt) => {};
}

fn main() {
    demo!($v);
}

それがすべてmacro_rules行われるのを待ちますか？！ 忘れられたマクロ1.1が派生しました-ほんの一瞬です。 とはいえ、1つのトークンである$xは、設計上の欠陥IMOです。 cc @jseyfried

@dtolnay

@alexcrichtonrustc_copy_clone_markerと他のrustc_attrsはまだ私たちを噛んでいます。 serde-rs / serde＃577を参照してください。

ああ、それは悪いようです！ 上部のリストを更新します。 @nrcまたは@jseyfriedは、これにどのように取り組むかについて考えていますか？ 私はすべての展開順序にあまり精通していませんが、1つの#[derive]属性が展開されているときに、将来のすべての属性を丸呑みにして最初にそれを実行しようとする可能性がありますか？

@sfackler

複数の派生物によって読み取られる属性の処理は大きな苦痛です

あなたがリンクした例に完全に従っているかどうかはわかりませんが、詳しく説明していただけますか？

@alexcrichton例を挙げてください

#[derive(ToSql, FromSql)]
enum Foo {
    #[postgres(name = "bar")]
    Bar
}

#[postgres]属性は、 ToSqlおよびFromSql実装の生成方法を調整するために使用されます。 それ以外の場合は不明な属性であるため、最終出力の前に削除する必要がありますが、 ToSqlとFromSql実装は別々に実行されます。 実装を生成してから属性を削除するだけで単純な方法でそれを行うと、2番目の派生ではカスタマイズが失われます。

serde-deriveとpostgres-deriveは、両方の派生implの実装を、両方を同時に生成する同じ関数に転送することにより、現在これをハックしています。 コンパイラが削除してから現在呼び出されている#[derive]を再接続し、それを送信して展開する必要があります： https ：

@sfackler私は、同じ実装者からの派生物が残っていない場合にのみ、余分な属性を削除することによってもそれを行うことができると思います。 あなたのやり方は_肩をすくめる_方が良いかもしれません。

@sfacklerああ、

しかし、その論理はもろいのではないかと思います。 たとえば、 ToSql拡張している場合、 FromSqlの将来の拡張はどのように検出されますか？ 上記の@dtolnayのような#[cfg]背後にある可能性がありますか？ では、すべての場合に検出できるとは限りませんか？

@alexcrichtonはい、それはもろいので、本当の解決策が重要だと思われます。

#[cfg]と#[cfg_attr]は、派生する前に処理されませんか？

マクロ1.1apiは文字列で機能するため、次の3つの解決策しか想像できません。

1. そのままにして、マクロ2.0を待ちます
2. カスタム派生で未使用の属性を許可する
3. カスタム派生が属性名を現在のアイテムの特定のホワイトリストにプッシュできるようにすることで、マクロ1.1APIを拡張します

各オプションには、独自の長所/短所があります。
短所1：当面の間の脆弱な回避策
短所2：一部の未使用の属性は検出されません
短所3：暫定的な解決策のためのより多くのAPIサーフェス

属性を#[used(...)]ラップして、それらを保持し、同時にホワイトリストに登録することを検討しましたが、それはかなりばかげていて、不安定すぎます。

@alexcrichton

1つの#[derive]属性が展開されているとき、それは将来のすべての属性を丸呑みしようとする可能性があります

私はこの考えが好きです。 #[cfg]と#[cfg_attr]は#[derive]の前に処理されるため、 #[cfg]保護された#[derive]はこのアプローチでは問題になりません。 （または、属性ストリッピングの問題に対する@sfacklerの類似の解決策の場合）。

このアプローチでは、 @ sfacklerのソリューションが少し単純になります。これは、他の関連する派生が最後の属性にしか存在しないためです（ @eddybの提案によって物事が単純化されると思います）。

コントロール属性の問題の1つの可能性は、syntexのhttps://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/libにいくぶん似ている拡張後のコールバックを追加すること

派生implは独立していて、制御属性を削除することはできません。また、クリーンアップのためにすべての展開が完了した後に実行されるパスを登録できます。

ディーゼルも手動でこれを回避しています。 https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L101 -L112

@dtolnay複数の#[derive]属性に関する以前の懸念は、 @ jseyfriedのおかげでまもなく修正されるはずです。

synとquoteパッケージを使ってこれを試してみて、本当に前向きな経験をしました。 これは、安定したときに優れた機能になります。

属性の問題は現在、 serdeの派生ロジックの下流にある私のimplを噛んでいます。

派生コードで未使用の属性を無視するか、通常の派生の後に実行される遅い拡張を許可してそれらを削除することは、私にとって合理的な解決策のように思えます。

マクロに元のトークンストリームを変更するオプションがない場合は理想的です。これは、現在とマクロ2.0の間で実際に依存される可能性があり、後で削除するのが難しい危険な機能のようです。

そのため、関数ジェネリック内の型パスにセミコロンがありませんでした。rustcから次のエラーメッセージが表示されました。 どの派生マクロがlexエラーを引き起こしたか、どのトークンがそれを引き起こしたかなど、より多くの情報を提供できるかどうか疑問に思っています。

error: custom derive attribute panicked
  --> src/simple.rs:69:1
   |
69 | struct C(u64);
   | ^^^^^^^^^^^^^^
   |
   = help: message: Failure parsing derived impl: LexError { _inner: () }

LexErrorのテストケースを作成しました。10月13日の夜に発生するようです（rustupには更新がありませんでした） https://github.com/keeperofdakeys/proc_macro_derive_test。

@ rust-lang / lang派生物が注釈付きアイテムを変更できるかどうかの問題について議論する必要があると思います。 それを可能にするのは簡単な解決策ですが、ユーザーの期待に反しているようで、かなり人気がないようです。 私はまだ現在の解決策を好みます-シンプルさは素晴らしく、提案された代替案のどれも私を非常に優れているとは思いません。

アイテムを変更できる場合は、属性を制御するためのソリューションが必要になります。 （将来的に）非派生属性マクロが可能である限り、派生がアイテムを変更する機能を維持することについて、私は特に強く感じているとは思いません。

誰かが「変更」を定義する必要があります。 構造体のメンバーを変更することについて話しているのですか、それともコンパイラが未知の属性について文句を言うのを防ぐために属性を取り除くことについて話しているだけですか？

構造体のメンバーを変更することについて話している場合、私の意見では、おそらく最善の解決策は、他のすべての前に展開される各構造体で1つの構造体変更マクロのみを許可することです。 それは明確に定義され、（私の意見では）期待される振る舞いをするでしょう。

属性のストリッピングについてのみ話している場合は、マクロの裁量に任せるのではなく、マクロメカニズム自体に属性を統合する方法があるはずです。

派生がどのように動作するかについての私の直感は、それがimplを追加するということです。 エンドユーザーにとって、derivesはimplsを追加し、他に何もしないように見えるはずです。 特に、他の派生物にとって重要な方法で構造体を変更するべきではないため、順序に依存しないようにする必要があります。 これが派生の動作方法であることに同意しますか、それとも派生がアタッチされた型に対して変換を実行できる必要があると人々は考えますか？

これに同意すると、問題は次のようになります。公開するインターフェイスでこれを強制するのか、それとも作成者にこれを強制するように任せるのか。 ここでは、2つの相反する問題があるようです。

• 派生の動作コントラクトを強制することは、確かに私にはRustソリューションのように思えます。
• serdeとdeiselをその制約で機能させるには、多くの課題があります。

そしてもちろん、他の属性が構造体をどのように変更するかは、派生の方法、具体的にはどのように動作するかとは無関係のようです。

注釈付きアイテムを削除する機能により、現在のシステムが他の方法では果たせない多くの役割を果たすことができることは注目に値します。

@sgrifdeiselが

@withoutboatsその90％はhttps://github.com/diesel-rs/diesel/blob/master/diesel/src/macros/macros_from_codegen.rs#L12-L18 。 それを超えて、入力トークンストリームの何かに触れるのは、注釈を取り除くことだけです。 https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L109 -L120

@sgrifまた、カスタム派生を悪用して、手続き型のbangマクロを取得しました。 個人的には、マクロ1.1に手続き型のバングマクロシステムがあり、この機能を乱用しすぎないようにすることを強く望んでいます。 マクロに渡されたTokenStreamに存在しないすべての識別子が衛生状態で隠されているなど、手間がかかるが単純な衛生状態の場合は、ほぼ同じ手順のバングマクロストーリーを実行することも良い方法だと思います。それがどのように見えるか正確にはわかりません）、カスタム派生を悪用する代わりにそれを使用してから、カスタム派生が存在する構造体を変更できないようにします。 そうすることで、さらに多くのクレートを有効にし、UXを改善し、派生を正気にすることができます。

ただし、deriveを単純なマクロとして保持するという議論は理解できます。

私の見解では、マクロ1.1の目標は、可能な限り多くのニーズを満たすために可能な限り柔軟であり、メンテナンスの負担が少ないため、マクロ2.0までの迅速な安定化と一時的なギャップとして機能することができます。 私の意見では、現在の設計はその役割に非常によく適合しています。

この役割を恒久的に果たすことを意図した何かについて話していたら、私はそれに反対するでしょう

私は間違っているかもしれませんが、RFCを読んだところ、これは永続的に派生する動作の基礎となることを目的としています。 つまり、将来的にはさらに多くのメソッドがTokenStreamに追加されますが、派生マクロはこのAPIを使用します。これにより、現在、注釈付きアイテムに対して任意のミューテーションを実行できます（この機能は、deiselのユースケースに必要です）。 ）。

デリバティブがこれを永続的に実行できるようにすることについて、私はかなり否定的に感じています。 これが将来のある時点でmacro_rulesマクロとともに非推奨になるシステムであり、マクロ2.0では、より制限された別の派生APIが優先されることを認める場合、私はそれでより快適に。

デコレータを何でもできるトランスフォーマーとしてサポートするつもりのようです。
そして、属性に入力のない単純なデコレータとして公開された派生。

@withoutboats ：serdeは、implの生成方法を変更するための多くの属性をサポートしているため、処理後にそれらを削除するか、無視する機能が絶対に必要です。 それが役に立ったら、自分たちでやりたいのではなく、削除する必要のある属性のリストをコンパイラーに提供することができます。

@eddyb私はデコレートが何でもできることに賛成ですが、（長期的には）

@ericktそうです。 長期的には、これらの属性を削除するのは派生者ではなく、no-opカスタム属性として登録するのが理想的な解決策になると思います。 しかし、それは短期的には実現可能ではありません。

長期的には、これらの属性を削除するのは派生者ではなく、no-opカスタム属性として登録するのが理想的な解決策になると思います。 しかし、それは短期的には実現可能ではありません。

私はこれを短期的に実行不可能にするコンパイラの内部に精通していませんが、カスタム派生プラグインが削除する予定のカスタム属性のリストを表示し、属性のその他の変換を拒否することは可能でしょうか？オリジナルアイテム？

また、Dieselは、すべてのカスタム属性を1つの名前で持つというSerdeのアプローチに従わないことにも気付きました（たとえば、Dieselの#[table_name = "name"]ではなく#[serde(rename = "name")] ）。単一のカスタム属性名だけの場合、実装が簡素化されますか？リストの代わりに登録されましたか？

コントロール属性の問題の1つの可能性は、syntexのhttps://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/libにいくぶん似ている拡張後のコールバックを追加すること

派生implは独立していて、制御属性を削除することはできません。また、クリーンアップのためにすべての展開が完了した後に実行されるパスを登録できます。

マクロ1.1の拡張後のコールバックをpost-expansionに実装しました。 派生implは独立していて、コントロール属性を削除することはできません。また、属性を削除するためにすべての展開が行われた後に実行されるパスを登録できます。

本日、langチームミーティングで変更/注文の問題について話し合いました。 ユーザーの期待に応え、単純にするために（設計の観点から、上に重ねられたハックが多すぎず、解読/デバッグエラーの影響を受けにくい）という要望がありました。 ターゲットデータの変更は驚くべきものですが、安全ではないことに注意してください。 また、やる気のある理由ではなく、それ自体のために純粋になりがちであると感じられました。

結局、ソースを変更しない派生物の方がおそらく優れていると判断し、そのモデルに変更する必要があります。 それはFCP期間を延長することを意味するかもしれません。 ストリッピング属性を処理するための特別なメカニズムがあるべきだとは思いませんでした。 むしろ、コンパイラが属性を処理する方法は、マクロによって使用される属性がプログラムに残ることを可能にする必要があります。 RFC 1755は、これを考慮に入れる必要があります。

これにより、一部のカスタム派生ユーザーの安定化が遅れます。 ただし、派生のほとんどの使用（特にユーザーを安定したツールチェーンから遠ざけるもの）は属性を使用しないため、たとえば、Serdeのほとんどのユーザーはすぐに安定に移行できるようになります。 属性が必要なものは、数サイクル長くかかりますが、一般的なケースには影響しません。

cc @ alexcrichton 、 @ dtolnay 、 @ sgrif 、 @ erickt-考え？

属性は、おそらくあなたが提案するよりもSerdeとDieselでより一般的に使用されます。 私自身の経験から、Serdeを使用するすべてのプログラムが属性を使用していると確信しています。 Dieselでは、間違いなく属性を使用します。どのデータベーステーブルが構造体にマップされているかをdiesel_codegenに伝えるために必要だと思います。

そうは言っても、カスタム派生に構造体を変更させないことは、私にとって正しい選択のように思えます。 それは全体を単純化するだけで、多くの奇妙なエッジケースを防ぎます。 すばやく実行するよりも正しく実行することが重要です。そのため、機能をもう少し不安定な状態に保つ必要がある場合は、それでも問題ないようです。

ターゲットデータの変更は驚くべきものですが、安全ではないことに注意してください。

安全でない特性を導き出さない限り、それは安全ではありません。

私の意見では、カスタム派生のユースケースの1つは、安全でないとマークされた特性を安全な方法で実装することです。たとえば、実装される構造体のメンバーのレイアウトを正確に記述しなければならない特性などです。

私のasn1クレートには、些細な使用法以外の属性も必要なので、カスタム属性が着地するまで効果的に待つ必要があります。

カスタム属性rfcを2つに分割するのは良い考えですか？

1. 一般にカスタム属性の表記法と名前空間を提供するrfc（安定版でno-op属性を許可）。
2. 定義方法のRFC、およびカスタム属性マクロの実行に関するセマンティクス。

カスタム属性マクロは、肉付けする場合に多くのことを必要とするもののように見えます。 したがって、rfcを2つに分割すると、カスタム派生パッケージの安定した属性がより早く提供される可能性があります。

これは、属性が名前空間であり、意図的であることも意味します（つまり、クレートの属性を使用するには、外部クレートが必要です）。 これは、同じ属性名を使用する2つのカスタム派生マクロを防ぐための良い方法であると予測できます。 ここでの良い期待は、属性に特性が含まれているクレートの名前を使用することです。

この実装が通常のname!マクロを含まない理由はありますか？ 通常のマクロの単純なTokenStream 、 TokenStream出力は、複雑な文法のコンパイル時間が30秒を超える害虫に非常に役立ちます。

@dragostis rfcの要約を引用するには：

コンパイラで今日の手続き型マクロシステムの非常に小さな断片を抽出します。これは、カスタム派生機能などの基本機能を取得するのに十分であり、最終的には安定したAPIになります。 これらの機能がコンパイラにメンテナンスの負担をかけないようにするだけでなく、同時に「完璧なマクロシステム」に十分な機能を提供しようとしないでください。 全体として、これは公式の「マクロ2.0」に向けた段階的なステップと見なす必要があります。

または、より実際的な用語では、現在構築しているクロージャーシステムと同じように、適切に機能する手続き型マクロシステムを取得するには、多くの設計とテストが必要になります。 serdeやdieselようなクレートには、適切なカスタム派生機能がないために深刻なユーザビリティの問題があるため、今すぐ修正するための一時的な対策を講じましょう。手続き型マクロシステム。 synとquote箱は、この良い例です。

@keeperofdakeysうん、わかった。 私はマクロ2.0の実装を求めているのではなく、別の属性を追加するための負担があるかどうか疑問に思っています。たとえば、通常のマクロの派生設計のみを反映する最小限の実装であるproc_macroです。 害虫の例では、 structパーサーを単純に導出しますが、 struct自体からは導出せず、 {}間で定義された単純な文法から導出します。 しかし、私は死んだ議論を掘り下げていないことを願っています！

@dragostis私は少し前に内部でこの可能性を持ち出しました。 あなたはそこで応答を読むことができます： https ：

@nrc

また、やる気のある理由よりも、それ自体のために純粋さを求める傾向があるのではないかと感じました。

これに関する1つの注意：パラメトリシティや専門化などの難しい決定を下さなければならなかった多くの場合、「純度」の関連する概念を静的に保証することは困難/不可能です。 しかし、この場合、構造によってそれを保証することは実際には非常に簡単であり、派生の順序の重要性を排除することは、ユーザーにとってかなり強力な単純化のように思えます。

安定性に関しては、属性を無視するための不安定なメカニズムを追加することを検討できます。これは、夜間に使用する必要がある場合でも、実際には安定しています（APIが破損する傾向がないという点で）。 このようなサイドチャネルの安定化を検討することもできます。利用可能になったら、より一般的なメカニズムを優先して非推奨にする予定です。 または、 @ keeperofdakeysの提案を検討して、当面の懸念に対処する一般的な属性ソリューションの一部をすばやくプッシュすることもできます。

私の見解では、これらの懸念のいずれも、マクロ1.1がSerdeで広く使用可能であり、少なくとも「事実上」安定している（つまり、壊れていない）ことを大幅に妨げないことが重要です。

@sgrif

この役割を恒久的に果たすことを意図した何かについて話していたら、私はそれに反対するでしょう

@withoutboatsをエコーし​​、現在の意図は、マクロ2.0を出荷する場合でもマクロ思いました。 ただし、これは再考できることです。最終的なシステムが導入されたら非推奨にすることを目的として、今日のmacro_rulesのように考えることができます。

カスタム派生での属性の使用に関する私の印象は、 @ jimmycuadraの印象に似ていました。つまり、それらはかなり一般的に使用されています。 私は、カスタム属性が多くのディーゼルのユースケースにとって重要であると信じています（しかし、私が間違っている場合は訂正してください）。

その意味で、私はそれらの属性について前進するための最良の方法が何であるかを100％確信していません。 マクロ1.1を安定させるのは恥ずべきことですが、そもそもマクロ1.1をすばやく安定させるという目的をやや損なうため、（たとえそれが毎晩「事実上安定している」としても）多くのユーザーを毎晩残します。 言い換えれば、マクロ1.1ユーザーの大多数を_実際に_安定したRustに引き込まないのであれば、マクロ1.1を安定させるのは待つことができると思います。

しかし、私を悩ませてきた1つのポイントは、カスタム属性が長期的にどのように見えるか、そして現在のマクロ1.1システムでそれを合理化すると私たちが考えることです。 カスタム属性の現在のRFCでは、クレートはクレートの上部に属性のホワイトリストに登録された名前空間を宣言する必要があります。 つまり、カスタム派生でカスタム属性を使用することは、他の場所でカスタム属性を使用することとは根本的に異なります。 その切断は、人間工学的で「驚き最小の」観点から私を心配しますが、RFCを微調整するための強制機能としても見ています（たとえば、 serdeクレートにリンクすると、serde属性を自動的にホワイトリストに登録できる可能性があります）。

全体として、今日のマクロ1.1システムを完全に安定化させて、個人的には順調に進んでいます。 つまり、カスタム派生展開関数が構造体を受け取り、それを保持したい場合は構造体も返す必要があるという事実を安定させます。

私はrustc-serializeからserdeに切り替える傾向があります。serdeのコード生成は制御属性をサポートしているからです。

マクロ1.1を拡張して、派生属性自体への引数をサポートすることができます。 これは一般的には良いことのように思われ、短期的には制御属性の欠如を回避するために悪用される可能性があります。

同上@jimmycuadraと@sfackler 、属性は@nrcのコメントがそれらを健全にするよりも

ここでの正しい動きについてはまだ意見がありませんが、属性なしで安定した場合は、ドキュメントコメントを解析して属性を引き出すことを強く検討することを知っています。 多くの人は、次のように書くためだけにビルドスクリプトを扱いたくないと思います。

#[serde(skip_serializing)]

.. の代わりに：

/// <!-- serde(skip_serializing) -->

@tomaka

私の意見では、カスタム派生のユースケースの1つは、安全でないとマークされた特性を安全な方法で実装することです。たとえば、実装される構造体のメンバーのレイアウトを正確に記述しなければならない特性などです。

この点で、私のコメントについてどう思いますか？ 満足のいくパターンであることがわかりました。

私は一つのことを明確にしたい：

カスタム属性を削除することは、人々がカスタム派生で行う主なことですか？

私が行うには、いくつかのハッキングがいることを知っているfoo!これらのユースケースはどのように中央-タイプのコンテキストで拡大（例えば、@sgrifはディーゼルで、このようなユースケースを述べ、私は@tomakaがあまりにも1に述べたと思います） ？

私が尋ねる理由はこれです：派生メカニズムがadd'limplsのリストだけを返すようにすることの利点がわかります。 特に、型宣言自体のスパンが正しいことを意味します。 そのタイプのコンテキストでホワイトリストに属性名のリストを提供できるようにする、手っ取り早いAPIをコンテキストに追加することは、属性を修正するのに十分簡単なようであり、いつでも非推奨にすることができます。

ただし、より多くのユースケースを有効にしたい場合（率直に言って、これらのユースケースはもう少し...驚くべきことですが、派生から何を期待するかを考えると）、これは機能しません。 その場合、私はおそらくそのまま安定させ、派生を書くためのより良い方法を支持するために「生のバイトから」APIを非推奨にすることを計画していると思います（結局のところ、私たちは人々がそうなることを本当に期待していませ

@nikomatsakis主な必要性は、属性を削除するのではなく、無視することです。 私はそれらを無視することの深刻な欠点を認識していません。 たとえば、main属性への追加パラメータを介して派生関数のホワイトリストを提供することは、手続き型マクロハックではなく真の派生であるすべての実際的なニーズに十分なはずです。

ええ、私はこれに関する2つのアプローチの間で引き裂かれていますが、どちらにも明らかな欠点があります。

1. 「単純な派生」アプローチ-追加のアイテムのみを生成するようにAPIを調整し、ユーザーが派生の一部としてカスタム属性を使用することを不安定にし、ディーゼルや他のクレートがジャンプして任意の手続き型マクロを取得する穴を閉じます。
2. 「計画的陳腐化」アプローチ-APIをそのまま安定させ、Nikoが命名について述べたように、いつか非推奨にすることを意図して、わずかな調整を加えます。 これには、すべてのカスタム派生作成者がいつかコードを書き直す必要があり、暫定期間中に予期しない動作が発生する可能性があります。

編集：しかし、 @ eddybのホワイトリストも有望に聞こえます。

@nrcが（IIRCはユーザークレートのホワイトリストについて話しているが）何か違うものを提案している

rust-cppでmacros1.1システムを悪用してきた任意の手続き型マクロは、implを追加して属性を無視する機能を提供する別のアプローチで完全に可能になります。

属性を無視する機能は不可欠だと思いますが、それ以外は、それを超えて構造体を変更できなくても問題ありません。

@sgrifが

@sfacklerによって提案されているように、カスタム派生に引数を取ることを許可することは、カスタム属性に関する決定を延期できるようにしながら、必要な機能をすべての人に提供する方法かもしれません。 見栄えも読みやすさも劣りますが、仕事は終わります。 例えば：

#[derive(Debug, Clone, Serialize(field("bar", rename = "baz")))]
pub struct Foo {
  pub bar: String,
}

このフォームは、カスタム属性に関する決定が下されると、後で非推奨になり、カスタム属性を優先する可能性があります。

Serdeと私のクレートの両方にフィー​​ルド/バリアント属性が必要です。 派生引数を使用してこれをエミュレートしようとしても意味がありません。属性が必要です。

これを安定させるためにどのような決定を下しても、マクロ2.0派生APIに切り替えるときに、カスタム派生マクロのユーザーがコードを変更する必要がない場合は便利です（明らかに、カスタム派生マクロの作成者は変更します）。 最も賢明な決定は、派生のために削除する属性のリストをコンパイラーに提供することであるように思われます。重要なことに、それらは_all_派生マクロが実行された後にのみ削除されます。 Serde、ディーゼル、および私のクレートはすべて、複数の派生マクロに対して同じ属性を必要とするという問題があります。

ストリッピング動作を使用すると、 @ dtolnayが別の派生マクロを追加して、残りの実行後に属性をストリッピングするために作成した拡張後のクレートは必要ありません。

FWIWこれらの属性を削除する唯一の理由は、HIRをスリムに保つことです。他のすべてに関する限り、使用済みとしてマークするだけで済みます。

カスタム属性を削除することは、人々がカスタム派生で行う主なことですか？

私はfooを行うためのいくつかのハックがあることを知っています！ タイプの文脈で拡大（例えば、@sgrifはディーゼルで、このようなユースケースを述べたように、私は@tomakaがあまりにも1に言及したと思う） -これらのユースケースは、どのように中央ですか？

カスタム派生は構造体を変更できないという事実に私は完全に大丈夫です。

安定したRustにプラグインがないことについて不平を言うことがよくあるので、カスタム派生物を見たとき、プラグインを持つ機会としてそれらを使用しました。 しかし、私は明らかに、カスタム派生物がそれらが設計されていないものをサポートしなければならないと主張するつもりはありません。

最近の毎晩に回帰があるようです。 エラーが発生する

Queryableは派生モードです

例をコンパイルするとき。

#[derive(Queryable)]
pub struct Post {
    pub id: i32,
    pub title: String,
    pub body: String,
    pub published: bool,
}

@sgrifこれは、他のマクロと同じ名前空間を使用するようにカスタム派生を変更した＃37198が原因bang!() （ #[attribute]マクロ、および#[derive(custom)]マクロがすべて共有されるように）同じ名前空間）。

この例では、 #[macro_use] extern crate diesel;はQueryableという名前のbangマクロをインポートし、 #[macro_use] extern crate diesel_codegen;はQueryableという名前のカスタム派生マクロをインポートします。これはbangマクロをサイレントに上書きします（ - #[macro_use]サイレント上書きは理想的ではありませんが、 use代わりに#[macro_use] use使用して外部クレートからマクロをインポートできれば、問題にはなりません！）。

このエラーは、カスタム派生の展開でのbangマクロの呼び出しQueryable!();が原因であると考えられます。これは、 dieselからのbangマクロではなく、 diesel_codegenからのカスタム派生に解決されます。

@jseyfried 3つの「種類」のマクロすべてに単一の名前空間を使用する理由は何ですか？ 関数と型を同じ名前空間を占めるものとして扱うことは理にかなっている以上に、属性とbangマクロを同じ名前空間を占めるものとして扱うことは私には意味がないようです（マクロの派生はさらに少なくなります）。

@withoutboatsこれは間違った例えだと思います。さまざまな種類のマクロが、さまざまな種類の値や型（関数や定数など）と同じように名前空間を共有していると思います。 名前空間を持つことには複雑なコストがかかり、私は私たちが持っている方が良いと信じているので、問題はなぜ異なる名前空間が必要なのかということです。 明らかに、逆互換の場合、マクロは関数や型とは異なる名前空間にある必要があります。

本当の問題は、 useを使用して、マクロを選択的にインポートしたり、名前を変更したりできないことです。 したがって、クレートユーザーには、マクロ名の衝突を回避する機能がありません。 同時に、ProcMacroクレートをインポートしてローカルマクロ名と衝突することは期待していません-派生マクロはderive_始まっていると思いましたか？

名前空間を持つことには複雑なコストがかかり、私は私たちが持っている方が良いと信じているので、問題はなぜ異なる名前空間が必要なのかということです。

アイテムは、互いにあいまいになる可能性がある場合にのみ名前空間を共有する必要があると思います。 constsとfnsは、どちらも式コンテキストでIDとして使用されるため、同じ名前空間にあります。 トレイトオブジェクトの構文のため、タイプとトレイトは同じ名前空間にあります。

これらの3種類のマクロは、すべて異なる方法で呼び出されます。 呼び出しにあいまいさが生じることは決してないため、名前空間を共有する必要があることは私には意味がありません。

実装の複雑さにはコストがかかりますが、これらを別々に名前空間化することによって、複雑さを_使用_することに大きなコストはないと思います。 言語機能の複雑さのコストについて考えるとき、私は通常、使用の複雑さについて考えます。

重大な変更ではない場合、_すべての_アイテムは同じ名前空間にある必要があると思いますか？ あなたの思考プロセスについて明確にしようとしています。

もう少し考えてみると、すべてのアイテムが含まれる名前空間は1つだけである必要があると言っても問題ありません。 「実際のコンストラクター」パターン全体はIMOを少し混乱させますが、それはRustが非マクロアイテムに対して行った決定ではないため、マクロアイテムが異なる名前空間を占める方が一貫性があり、期待されるようです。

本当の問題は、useを使用してマクロを選択的にインポートしたり名前を変更したりできないことです。

マクロ2.0でできるようになります。 ここでのモデルは基本的に一時的なハックです。

派生マクロはderive_で始まっていると思いましたか？

それは古いカスタム派生システムでした。マクロ1.1がこれを行うとは思いません。

実装の複雑さにはコストがかかりますが、使用の複雑さには大きなコストはないと思います

使用の定義にはコストがかかります。特に、ツールの使用が難しくなります（あまり議論しないかもしれませんが）。 また、言語の複雑さほど重要なのは実装の複雑さではないと思います（名前空間はコンパイラを複雑にしますが、これはそれほど重要ではないことに同意します）-ユーザーはRustを使用するためにこのことについて推論する必要があり、ノックオンがあります衛生やシャドウイングなどに影響を与え、事態をさらに複雑にします。

重大な変更ではない場合、すべてのアイテムが同じ名前空間にある必要があると思いますか？ あなたの思考プロセスについて明確にしようとしています。

それほど遠くまでは行きません-値と型を分離することには利点があると思いますが、確かに、単一の名前空間を持つ言語は、多くの方法で操作する方がはるかに優れています。

しかし、それはRustが非マクロアイテムに対して行った決定ではありません

対位法：モジュールとフィールドは値の名前空間にありますが、それらを使用できる場所は（私が思うに）他の値を使用できる場所とは異なります。

@keeperofdakeys

本当の問題は、 useを使用して、マクロを選択的にインポートしたり、名前を変更したりできないことです。

すぐに（〜1週間）機能ゲートの後ろでextern crateからuseマクロを実行できるようになります。https：//github.com/rust-lang/rfcs/pull/1561を参照してuse ingマクロを、カスタム派生自体とともに安定化することを決定する場合があります。

派生マクロはderive_始まると思いました

これは、古いスタイルのカスタム派生に当てはまりました。 マクロ1.1のカスタム派生では、 #[derive(Serialize)] （たとえば）はSerializeがカスタム派生マクロに解決されることを期待します。

@withoutboats

3つの「種類」のマクロすべてに単一の名前空間を使用する理由は何ですか？

• 優先順位：bangマクロと属性マクロは長い間名前空間を共有してきたので、その変更が行われるまで、カスタム派生物もその名前空間を共有する必要があると思います。
• 下位互換性：単一のマクロ名前空間から開始する場合、互換性を持って下位に分割できます。 複数のマクロ名前空間から始めると、永遠にそれらに固執します。
• シンプルさ：各マクロの「種類」に独自の名前空間がある場合、合計5つの名前空間があります。 したがって、 https：//github.com/rust-lang/rfcs/pull/1561が着陸した後、 use foo::bar;はbar （値、タイプ、バングマクロ）という名前の_5つの個別のアイテム_をインポートできます。など）、たとえば、bangマクロを再エクスポートするが、カスタム派生マクロは再エクスポートしない、またはカスタム派生マクロをbazとしてインポートする簡単な方法はありません。

下位互換性：単一のマクロ名前空間から開始する場合、互換性を持って下位に分割できます。 複数のマクロ名前空間から始めると、永遠にそれらに固執します。

これは、特に1.1が一時的なギャップであると想定されているため、説得力があります。 ：+1：

これは、たとえばPartialEq!というmacro_rulesマクロを持っている人のコードを壊しますか？

いいえ、 PartialEqはカスタム派生ではないため、今日のマクロ名前空間では定義されていません。
#[derive(Foo)]は、カスタム派生Foo探す前に、まずFooが「組み込み派生」（ PartialEq 、 Copyなど）であるかどうかを確認します。マクロ名前空間のFoo 。 ビルトインはderiveの定義にハードコードされています。

そうは言っても、最終的にPartialEq組み込みではなくプレリュードのカスタム派生にすることにした場合、あなたが説明したようにコードを壊す可能性があるので、今のところそれを将来証明するのは良い考えかもしれません。

属性の問題の提案（派生マクロが宣言されているアイテムを変更できず、装飾するだけのモデルで作業していると仮定）：

• 舞台裏では、カスタム派生マクロは、現在MultiItemModifier特性を実装しています。 マクロ2.0が引き続き特性を実装し、この特性がメカニズムの拡張性のために使用されることが計画です。 マクロである注釈付き関数は、この特性を実装します。 プラグインレジストラは使用しませんが、これは本質的に脱糖です。
• 特にマクロ1.1カスタム派生のためにCustomDerive特性を分割する必要があります。 一般的なケースでは、マクロの作成者はそれを見ることはありません。 ただし、関数で属性を使用するのではなく、トレイトを直接実装するオプションがあります（implで属性を再利用することを期待しています。おそらく、この登録メカニズムについて説明する必要があります）。
• 我々は、追加declare_attributesに関数をCustomDerive返すVec<String> 。 空のvecを返すデフォルトのimplがあります。
• マクロの作成者がこのメソッドを実装する場合、返された文字列の1つとまったく同じ名前の属性は、マクロに属していると見なされます。 このような属性はマクロのように検索されることはなく、カスタム属性のlintをトリガーしません。 属性は派生展開によってコードに残されますが、使用済みとしてマークされます。 派生展開によって変更されないそのような属性は、未使用の属性lintをトリガーします（カスタム属性lintはトリガーしません）。
• 将来的には、カスタム派生を含むマクロが使用できるスコープ属性を導入する可能性があります。これらはdeclare_attributes _追加_され、このメカニズムは非推奨になりません。
• 代替方法： declare_attributesによって返される文字列は、属性のパスプレフィックスとしてチェックされます。たとえば、 declare_attributesがvec!["foo::bar"]返した場合、 #[foo::bar::baz]と#[foo::bar::qux]は許可されます。

考え？ cc @alexcrichton @jseyfried @dtolnay @sgrif @erickt @ rust-lang / lang

@nrcは、そのメカニズムにより、 #[cfg(..)]などの_used_属性を偶然または故意に無効にすることができますか？ そして、それは変更できますか？

@nrc残念ながら、これらの制約があると実装がどのようになるかはよくわかりません。そのため、それが機能するかどうかは完全にはわかりません。

そうは言っても、トレイトのインスタンスはどこで作成されているので、トレイトとトレイトオブジェクトが機能するかどうかについては少し懐疑的です。

@nrcなぜこれが必須であり、derivwエクスパンダ関数を指定する属性のリストにすることができないのですか？ 例： #[proc_macro_derive(Serialize, uses_attrs(serde_foo, serde_bar))]など。

@ collin-kiegel派生アプリケーションのスコープにのみ適用できると思います。その場合、マクロ展開の前にcfgを適用する可能性があると思いますが、他の属性を無効にすることはおそらく予想される動作です（これは変更されましたが、覚えていません）前と後）。

@alexcrichton

そうは言っても、トレイトのインスタンスはどこで作成されているので、トレイトとトレイトオブジェクトが機能するかどうかについては少し懐疑的です。

うーん、良い点です。マクロ2.0ではこれに対処する必要があると思います。

@eddybこれは良い考えであり、おそらく短期的には簡単です。 命令型アプローチを好む私の理由は、それが一般的な拡張メカニズムであり、維持したいものであるのに対し、属性に物事を追加することはあまりうまくスケーリングせず、永遠に固執したいものではないかもしれないからです。 一方で、今は確かに簡単で、ぶらぶらしているのは悪いことではないように思われるので、もっと良い賭けかもしれないと思います。

巻き込まれて-私は国外に出て、その後病気になりました。 すべての種類のマクロが同じ名前空間を占めることは意味がないと思うので、 https：//github.com/rust-lang/rust/pull/37198に再度derive_Fooなどの名前空間にあることを期待します。 標準ライブラリでも同じ名前を使用する複数のタイプのマクロのユースケースがあります（例： #[cfg]およびcfg! ）

また、共有名前空間は少し厄介だと思います。 エンドユーザーの観点からは、ある種の互換性、あいまいさ、または何か面白いことが起こっているように見えるかもしれませんが、そうではありません。 このような「ランダムな」制限により、Rustを言語として理解するのが少し難しくなる可能性があると思います。

しかし、それはおそらく世界の終わりではないと思います。 将来的には、多くのことを壊すことなく、さまざまな名前空間が導入される可能性があるようです。

@sgrif @ collin-kiegel https://github.com/rust-lang/rust/issues/35900#issuecomment-256247659で単一のマクロ名前空間の理論的根拠を説明しました。

すべての種類のマクロが同じ名前空間を占めることは意味がないと思います

明確にするために、bangマクロと属性マクロは常に同じ名前空間を占めてきました。 ＃37198カスタム派生をこの名前空間に移動しました。

標準ライブラリでも同じ名前を使用する複数のタイプのマクロのユースケースがあります（例： #[cfg]およびcfg! ）

あるいは、 cfgは、bang呼び出しまたは属性呼び出しを介して使用できる単一のマクロと見なすことができます（現在、ユーザーがbangまたは属性を介して呼び出すことができるマクロを定義することはできませんが、マクロ2.0で許可することを決定するかもしれません）。

エンドユーザーの観点からは、ある種の互換性があるように見えるかもしれません

これは、2つのマクロが競合する場合に、明確なエラーメッセージで改善できると思います（今日のメッセージの改善に取り組みます）。

将来的には、多くのことを壊すことなく、さまざまな名前空間を導入できるようです。

マクロ名前空間の分割は完全に下位互換性があると思います（間違っている場合は訂正してください）。 これが、今日単一のマクロ名前空間を維持するための私の主な動機です。マクロ1.1に可能な限り将来の互換性を持たせたいと考えています。

最後に、bang /属性マクロとカスタム派生マクロの競合は実際にはまれだと思います。これは、bang /属性マクロは通常小文字であり、カスタム派生は通常大文字であるためです。 言い換えると、これらの命名規則に従っている場合、カスタム派生にはすでに独自の名前空間があります。

破損（https://github.com/diesel-rs/diesel/issues/485）は、 Queryable! { struct S; }や#[derive(Queryable)] struct S;サポートが原因のようです。 カスタム派生が安定したら、 Queryable! { struct S; }をサポートする必要がなくなるので、これは問題ではなくなりますよね？

それまでの間、 diesel更新して、

• Queryable!は、 #[macro_use] extern crate diesel_codegen;なくても引き続きサポートされ、
• #[derive(Queryable)]は、 Queryable!ではなく、 #[macro_use] extern crate diesel_codegen;サポートされています。

気軽にIRCで私にpingして話し合ってください。PRを書いていただければ幸いです。

@nrc @alexcrichton

そうは言っても、トレイトのインスタンスはどこで作成されているので、トレイトとトレイトオブジェクトが機能するかどうかについては少し懐疑的です。

@eddybに同意します。属性を処理する観点から、属性を拡張するだけで済みます。

しかし、より柔軟な拡張システムが必要な場合は、トレイトを使用することを想像していましたが、これらのトレイトは、 Self参照しないメソッドのコレクションとして定義されます。

trait CustomDerive {
     fn foo(); // note: no self
     fn bar(); // again, no self
}

次に、それをstruct my_annotation_type;ようなダミータイプ（属性と同じ名前を共有していると思いますか？）に実装し、トレイト解決を使用して<my_annotation as CustomDerive>::fooような関連関数を抽出します（おそらくメタデータを書き出すとき、私は推測します）。 重要なのは、 my_annotationインスタンスを作成する（または必要とする）ことは決してないということです。これは、関連する関数の束をまとめるための単なるグループ化メカニズムです。

確かにこれまでで最もエレガントなものではありませんが、より良い方法がわかりませんか？ エレガンスが、属性関数から始めたかった理由だと思います。 =）

名前空間に関しては、 @ sgrifは#[cfg]とcfg!例で良い例を示しています。 私は確かに#[derive(SomeTrait)]を望んでいて、 SomeTrait! { ... }ような...何かをするマクロを持っていることを想像することができます。 =）しかし、 @ jseyfriedは、_すでに_制限に達していない限り、下位互換性の良いケースにもなります。

私はデフォルトでより少ない名前空間を好む傾向があります。これは主に、値/型の名前空間を分割することで私たちが苦痛を感じるためです。 そうは言っても、既知の問題点のほとんどはここには当てはまらないと思います。

• use foo::barはbarという名前のモジュールをインポートする場合としない場合があり、したがってbar::bazような名前解決に関連する（または関連しない）可能性があるため、タイプ/値の分割は名前解決の苦痛です。
• 型/値の分割は、定数よりもジェネリックスにとって一種の苦痛ですが、その苦痛は、型と値の間の構文上の分割も原因です。

しかし、大体において、私たちは橋を渡ったので、「カスタム派生」をそれ自身の名前空間に住まわせることが特定の挑戦をもたらすかどうかはわかりませんね？

生成されたマクロにderive_プレフィックスを追加して、それらを疑似名前空間にすることができます。 その変更を加えたいのであれば、今がその時です。

@keeperofdakeysこれは、カスタムderive_*という名前を付けることを決定したカスタム派生物の作成者と同等ではないでしょうか。 とにかく、 derive_*名前はエンドユーザーにとって醜すぎると思います。

@nikomatsakis

しかし、大体において、私たちは橋を渡ったので、「カスタム派生」をそれ自身の名前空間に住まわせることが特定の挑戦をもたらすかどうかはわかりませんね？

インポート解決アルゴリズムは、任意の数の名前空間を処理できますが、名前空間ごとに重要な量の作業を実行する可能性があります。 特に、インポートIと未使用の名前空間Sごとに、解決策IがS失敗することが証明されます（https：// githubを参照）。 com / rust-lang / rfcs / pull / 1560＃issuecomment-209119266）。 この証明では、関連する不確定なインポートを検索するために、グロブインポートグラフ（頂点がモジュールでエッジがグロブインポート）のDFSが必要になることがよくあります。

ただし、この余分な名前空間ごとの作業は実際には違いがない可能性があり、必要に応じて回避できます（https://github.com/rust-lang/rfcs/pull/1560#issuecomment-209119266を参照）。マクロ名前空間にのみ適用されるマイナーな制限。

＃37198で名前空間をマージして、ほとんどの場合オプションを開いたままにしました。実際には制限されるとは思わなかったためです。 人々が今日それを望んでいて、@ rust-lang / langが永遠に複数のマクロ名前空間を持っていても大丈夫なら、私は異議はありません。

@nikomatsakis

不思議なことに、あなたの戦略はうまくいくと思います。 私の個人的な感覚は、奇妙さはその重みを引っ張らないということです（たとえば、今日私たちが持っているものは私にとっては問題ありません）が、どちらの方法でも実装可能である必要があります。

@alexcrichtonは、以前書いたと思いますが、（もしあれば）もっとパワーが必要になるまで待って幸せです。そうすれば、私が説明した特性のようなこと、あるいはもっと良いことをすることができます。 今のところ、 fn適用される属性を拡張するだけで十分だと思います。

私は興味を持ち、このアイデアの基本的な実装を開始しました（proc_macro関数の属性を使用して、アイテムで使用されているとマークされる属性の名前を示します）。

まだ安定する準備ができていないことが明らかなため、FCPタグをクリアしました。 私は会話の状態を要約するように努力し、特に、確固たる決定やコードの貢献がまだ必要なエラーを強調します。

質問1：カスタム派生マクロは、歩いているアイテムを変更できる必要がありますか？

• もちろん、_実際に_そうすべきだとは誰も考えていません。
• それは別のモードで、当初はYAGNIの精神で拒否されました
• フィールド名のセットなどを変更する派生物はうまく構成されず、アプリケーションの順序が表示されます。
  その危険性は2つのことによって軽減されます：
  
  
  
  • フィールド名/タイプへの変更は、実際には透過的に行うことはできません
  
  
  • 安全性が重要なマクロは、完全に明示的な構造体パターンを使用して、フィールドのセットを変更した人がいないことを確認できます。
  
  
• 一方、カスタム派生が新しいimplを返すだけでよいと言う場合
  
  
  
  • スパン情報が優れています
  
  
  • カスタム派生は書くのが簡単です
  
  
• _しかし_多くのカスタム派生物は、カスタム属性を使用して拡張をガイドし、それらは警告/エラーを生成します
  
  
  
  • 現在の技術は、ASTからそれらを取り除くことです
  
  
• _また：_私たちはこのようなものをできるだけ早く世界に送り出したいので、長い実験や大幅な変更をしたくありません

提案：

• すべてをそのままにして、後で非推奨にするかもしれません
  
  
  
  • 便利、やや不幸
  
  
• 属性のホワイトリストで#[proc_macro]を拡張し、それらを「使用済み」と見なして無視するようにrustcに指示します
  
  
  
  • シンプルで、主なユースケースをカバーしています
  
  
  • しかし、誰かがそれを実装する必要があります（多分@keeperofdakeys！ ）
  
  

質問2：カスタム派生は他のマクロと同じ名前空間を共有する必要がありますか？

引数：

• 一般に、名前空間が少ないほど優れており、解決の実行時間が短縮されます
• 下位互換性、後で名前空間を削除することはできません
• 大文字の規則（ #[derive(Foo)]とfoo! ）はすでに目的を果たしています
• use foo::Barは、とにかくどの名前空間を意味するのかを実際に区別できないため、共有しない場合は混乱の余地が少なくなります

反対意見：

• #[cfg()] vs cfg!()は今日発生します（ただし、どちらもカス​​タム派生ではありません。これは、実行中のコンテキストをマクロに通知することで対応できます）
• _user_の観点から、誰が参照しているのか混乱する可能性は低い

提案：

• 「カスタム派生」名前空間に分割
• 現状維持

他のもの？

他に未解決の質問はありますか？

突然変異の問題に対する潜在的な解決策：

タイプTokenStream -> TokenStreamのカスタム派生物の代わりに、タイプ
Item -> TokenStream 、ここでItemは不透明（OPAQUE）型で、次の2つの方法で始まります。

• item.tokens() 、これは今日渡されるTokenStreamを返します。
• item.use_attrs(name) 。これにより、指定された名前のすべての属性が使用済みとしてマークされます。

返されるTokenStreamは、派生したimplのみが含まれます。
最終的には、便利な関数（アイテムのフィールド/バリアントの反復処理など）またはsyntax_ext::deriving::genericような高レベルの派生APIを使用してItemのAPIに追加できます。

ホワイトリストに登録された属性を#[proc_macro_derive]許可するように実装できれば幸いItem -> TokenStream提案。

基になるアイテムを変更する可能性のあるカスタム派生を安定させるのは間違いだと思います。 ミューテーションを許可することによって犠牲にするスパン情報は、すでに問題を引き起こしています。たとえば、修正＃37563と修正＃36218のどちらかを選択する必要があります。

命令型ホワイトリストの魅力は本当にわかりませんが、誰かがユースケースを思い付くことができますか？

よくわかりませんが、このコードをコンパイルするのは意図的/望ましいですか？

#![feature(proc_macro)]

#[proc_macro_derive(Whatever)]
struct Foo {}

@eddyb命令型ホワイトリストの本質的な魅力があるかどうかは
Item -> TokenStreamは、より多くの種類の宣言型属性を追加するよりも、 ItemのAPIを拡張する方が簡単なことです。 そうは言っても、これについてもう少し考えてみると、 TokenStreamよりもTokenStream Itemを必要とする他のユースケースはあまりないかもしれないので、 TokenStream -> TokenStream宣言型ホワイトリストを使用した

マクロ2.0はこのAPIに取って代わりますか？ もしそうなら、拡張性は実際の懸念事項ではなく、 Item -> TokenStream apiはあまり魅力的ではないようです。

@keeperofdakeys RFCによると：

全体として、これは公式の「マクロ2.0」に向けた段階的なステップと見なす必要があります。

マクロ1.1の目的は、膨大な量の機能を安定させることなく、精神と実装においてマクロ2.0に可能な限り近づけることです。 その意味で、安定したマクロ1.1が与えられれば、機能を逆方向に階層化して、互換性を持ってマクロ2.0に到達できるようにすることが意図されています。

https://github.com/rust-lang/rfcs/pull/1681#issuecomment-233449053およびhttps://github.com/rust-lang/rfcs/pull/1681#issuecomment-233708395およびhttps：// github。 com / rust-lang / rfcs / pull / 1681＃issuecomment -239558657は、マクロ2.0が到着したときに、「限定された」非推奨のみが予想されることを示しているようです。 特に、「文字列化トークンツリーのパターンは、実際に非推奨にならない限り、好ましくないものになります」。

@eddyb

命令型ホワイトリストの魅力は本当にわかりませんが、誰かがユースケースを思い付くことができますか？

そうですね、属性の名前が何らかの方法で動的に生成される場合を想像できます（おそらく、タイプまたはフィールドの名前に基づいていますか？）-したがって、事前に宣言することはできません。 しかし、一種の人工的なようであり、特に良い習慣のようではありません。

@jseyfriedの代替手段は魅力的だと思います。これは、属性を使用済みとしてマークするという命令的な性質のためではなく、 Item APIが時間の経過とともに豊富になる可能性があるためです。 つまり、非常に構造化された方法でフィールドのセットを歩くことをサポートしたり、自由に使用できるより多くのデータ（名前の解決など）へのアクセスを提供したりする場合があります。

もちろん、これの一部は、（最終的には）何らかの形式の標準ASTAPIからも取得されます。

タイミングに関する注意：私は本当に、マクロ1.1が次のサイクルで安定するのを見たいと思っています。 私たちがブロックされているものは、最終的にはかなりマイナーな感じがします。

その精神で、私が説明した問題についての私の見解：

1. 宣言型の#[proc_macro]拡張子_または_型をItem変更することに満足しています。 また、どちらを選んでも、良いアイデアだと思えば、将来的にはもう一方を採用できる可能性があると思います。 最初に実装された方を選びたいと思います。 =）
2. 複数の名前空間については、今のところ同じ名前空間に留めておくべきだと思います。 私にとって、下位互換性（つまり、オプションを開いたままにする）と、大文字の使用によって「カスタム派生」マクロが実際には他のものとすでに区別されているという事実の組み合わせは魅力的です。 #[cfg]とcfg!区別することは、他の方法で処理できるもののように感じます。または、必要に応じて、分割名前空間を_then_導入できます。 統一された名前空間を持つことは、特にカスタム派生のユースケースに悪影響を及ぼしているようには見えません。これは、とにかく安定化について話している唯一のことです。 正しい？

@nikomatsakisあなたの要約は正確に聞こえます、それを書いてくれてありがとう！ Rust 1.14でマクロ1.1が取得されないのは残念ですが、これらは論争の的となる問題であることを理解しています。

私の個人的な感覚は、カスタム派生が属性を削除する必要があり、名前空間が1つしかない場合、すべてをそのまま安定させることです。

Item -> TokenStream APIに完全には従いませんが、返されたトークンストリームには、元のアイテムが含まれていますか、それとも追加されたimplだけが含まれていますか？ それは&mut Itemかかるはずだということですか？

@ est31あなたのコメントはバグのように聞こえますが、別の問題を開くことができますか？

@nikomatsakisのコメントにほぼ完全に同意します。 派生する重要なことは、それらがアタッチされているアイテムを変更する自由な統治を持っていないことだと思いますが、提案された実装はすべて私には問題ないようです。

統一された名前空間を持つことは、特にカスタム派生のユースケースに悪影響を及ぼしているようには見えません。これは、とにかく安定化について話している唯一のことです。 正しい？

この問題は、現在Queryable!と呼ばれるマクロがあり、構造体をラップしてQueryableを導出できるディーゼルが壊れているために発生しました。

現在ディーゼルを使用も維持もしていない人として（つまり、私が提案しようとしていることに影響されない人として：sweat_smile :)、今のところ1つの名前空間を保持し、ディーゼルが名前を変更するのが最善だと思います。それらのマクロをderive_Queryable!またはそのようなものに。 とにかくこれが安定すると、非推奨になりますよね？

提案された機能のPRhttps：//github.com/rust-lang/rust/pull/37614を作成しました。 別の属性#[proc_macro_attributes(..)]し、返されたTokenStreamアイテムを返す必要がなくなりました。

procマクロが$crateどのように処理するかを理解するために、＃37637を提出しました。

明確にするために、このユースケースはシステムの大丈夫または誤用と見なされますか？

ここでは、既存の構造体と属性に基づいて新しい構造体を生成します。これにより、物事を1つの構造体に統合できるため、デザインが非常に気に入っています。

ただし、この種の実装を許可しないようにシステムが後で変更される可能性がある場合は、システムにさらに力を入れるのではなく、今すぐ停止する可能性があります（現在の実装は概念実証にすぎません）。

@TheNeikos

後方互換性のない主な変更は、アイテムを変更できなくなったことです（TokenStreamに戻さない）。 impl以外のものを導出することは意図されていないと思いますが、これを行うことを妨げるものは何もありません。 名前の衝突に注意する必要があります。

もう1つの主な変更点は、アイテムでカスタム属性エラーをトリガーしてはならない属性名のリストを提供できることです。

RE：ディーゼルでの名前空間の競合。 この機能が安定したら、これらのマクロを非推奨にするかどうかはわかりませんが、コンパイラ拡張機能のないものに対する要望がまだあるかどうかによって異なります。 それは疑わしいです。 内部でのテストにはまだ役立ちますが、名前を変更しても問題ありません。

入力ストリームを変更する機能を失うのは残念だと思います。 注釈が付けられているアイテムを削除できるので、このシステムでもバングマクロを使用できます。 私は懸念を理解していますが、それらに対するその能力を失うことは残念です。

@TheNeikos @sgrif私の見解では、入力を大幅に変更するものは派生物ではないため、ここで取り上げることを意図していません。 汎用のprocマクロにカスタム派生を使用することはやや危険（衛生状態の欠如など）だと思うので、私はそれを奨励することに熱心ではありません。

アイテムを変更できないということは、アイテムのスパン情報が保持されることを意味します。これにより、アイテムのエラーメッセージがより明確になります（また、派生出力のエラーメッセージがアイテムのスパンではなく、派生属性のスパンを指すようになります）。 適切な手続き型マクロが本当に必要な場合に、この機能を悪用させる正当な理由はわかりません。

@TheNeikos派生する構造体を

私が考えることに関しては、慣用的です。 新しいタイプを生成するのは問題ないと思いますが、それらのタイプが、派生している特性に関連付けられたタイプである場合は、はるかに優れています。 たとえば、型のIntoIteratorを導出できたとしたら、 Iterator構造体を作成する必要があります。 概念的には、このタイプの動作を導出する必要がありますが、その動作は「特性の暗黙」ではない可能性があります。

@sgrif

入力ストリームを変更する機能を失うのは残念だと思います。 注釈が付けられているアイテムを削除できるので、このシステムでもバングマクロを使用できます。 私は懸念を理解していますが、それらに対するその能力を失うことは残念です。

うーん、私は間違いなく同情的ですが、明らかに（ @nrcが指摘したように）これはシステムが設計されたものではなく、さまざまな粗いエッジを露出する傾向があります。 これは、ユースケースではおそらく問題ではありません。 重要な質問は、「bangmacros1.1」のようなものにどれだけ迅速に移行できるかということだと思います。

PRが統合されたので、次の夜に次の変更を確認できるはずです。 proc_macro_derive関数はアイテムを返さないはずです（そうすると、タイプが2回定義されているというエラーがトリガーされます）。この#[proc_macro_derive(Derive, attributes(Foo, Bar)]ように、属性名のリストをホワイトリストに提供できるようになりました。

cc @ dtolnay 、 @ sgrif ^

残念ながらすぐに破損の原因になります

はい、 https：//github.com/serde-rs/serde/issues/614を提出して追跡しました。

https://github.com/diesel-rs/diesel/pull/493でディーゼルの破損を修正したと思います。ナイトリーが再び構築されたら、確実にわかります。

したがって、このスレッドを正しく読んでいる場合、procマクロは最初のアイテムに追加された追加のアイテムしか出力できないため、最初のアイテムに注釈を追加することもできませんか？ （「兄弟注釈」を許可するという言及がありますが、それ以外は何もありません。）

私の（小さな、未公開の）クレートに#[derive(newtype)] procマクロがあり、注釈を付けている構造体に基づいて、他の#[derive()]の別のセットに展開されます。 たとえば、 #[derive(newtype)] struct Foo(u64)は#[derive(Clone, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)] struct Foo(u64); 、 #[derive(newtype)] struct Foo(::semver::VersionReq)は#[derive(Clone, Debug, PartialEq)] struct Foo(::semver::VersionReq);ます。 したがって、構造体メンバーはこのマクロによって変更されませんが、他の派生物が追加されます（これらも構造体を変更しません）。

そのような構造体は数十あり、このマクロが展開された後、それぞれに10個ほどの新しい派生物があります。 すべてのu64ニュータイプにもう1つのトレイトを実装したい場合は、すべての構造体ではなく、 newtypeマクロコードの1か所で派生セットを変更できます。

以前はこのためにmacro_rules newtype!マクロを使用していましたが、次の理由でprocマクロに切り替えました。

• ドキュメントコメントの有無、 pub有無などは、マクロマッチアームの組み合わせ数を必要とせずに無料で処理されます。
• 組み合わせマクロマッチアームを書いたとしても、競合しない順序を見つけるのは大変でした。

残念ながら、いいえ、これまでのようにこれを行うことはできなくなりました。

この機能の将来の互換性が安定していることについて：プラグイン関数は「純粋」である必要はないため、処理される関数に与えられたオブジェクトの順序が将来変更された場合、またはrustcがマルチスレッドを実装した場合、重大な変更になりますか？コンパイルしますか？

@ est31時間があれば、周りで言及されているIPC分離のことを

最新の変更後、ディーゼルでICEが常に表示されています。

../src/librustc_metadata/decoder.rs:490：エントリ：IDが見つかりません：番号28のクレート「diesel_codegen」のDefIndex（1）

@sgrifは＃37788で修正され、＃37793で修正されます（明日の夜に終わることを願っています...）。

@ est31この時間では、ナイトリービルドが開始する前にマージするのは遅すぎます。

https://github.com/rust-lang/rust/issues/37839は、それ自体がproc_macroクレートを使用するlibクレートの使用に関する問題です。 AFAICTテストは、procマクロモジュールのみをコンパイルするか、procマクロモジュールとprocマクロを直接参照するbinモジュールをコンパイルするため、この影響を受けません。

編集：修正されました！

@ Arnavion ＃37839で見た問題は通常の複雑化のために修正されていますが、＃37958で報告されているように、 --targetを使用すると壊れたままになります。 --targetを最小限のテストケースを提供しましたが、それでも壊れます。

@rfcbotfcpマージ

ホワイトリストに登録された属性機能が実装されたので、これを安定させる必要があると思います。 Serde、Diesel、およびその他のユーザー-現在のデザインが機能しない場合は、オブジェクトへの変更になります。 =）

cc @sgrif @erickt

チームメンバーの@nikomatsakisは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

• [x] @alexcrichton
• [x] @aturon
• [x] @brson
• [x] @eddyb
• [x] @japaric
• [x] @michaelwoerister
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @vadimcn
• [x] @withoutboats
• [x] @wycats

現在リストされている懸念はありません。

これらのレビューアがコンセンサスに達すると、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

近い将来、バングマクロが探求されるのを見たいです。 しかし、異議はありません。

@rfcbotレビュー

現在、TokenStreamが空のLexErrorの解析に失敗した場合、

はい、それはマクロの作者にとって便利でしょう。 エラーを見つけるために、ストリームをファイルに書き出してプレイグラウンドで表示することに頼らなければなりませんでした。

マクロに対してより良いバグレポートを提出するだけであれば、ユーザーにもメリットがあると思います。

https://github.com/rust-lang/rust/pull/38140で、カスタム派生宣言を公開するように強制しています。 いつの日かプライベート派生が必要になるかもしれないという理論は、定義関数の可視性に基づいてその区別をしたいと思うでしょう。 いずれにせよ、これは控えめな選択です。 この機能を安定させているので、マージする前に人々が見ることができるように、1日か2日マリネさせたいと思いました。

＃37480はクローズされており、チェックリストに反映されているはずです。

修繕

@pnkfelixあなたはPTOに参加していて、完全に参加していると思うので、私はあなたのためにあなたのボックスをチェックする自由を取りました。 そうでない場合はお知らせください。

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

psst @nikomatsakis 、 final-comment-periodラベルを追加できませんでした。追加してください。

差し迫った安定化は、上部のチェックリストに残っている既知のバグが最初に修正されることを前提としていますか？ それとも、安定化のためにブロックしていないのですか？

現在、2つあります。

• ＃36935には、解決したというコメントがあります。
• ＃36691は私にはブロックされていないようです。私が信じていることを壊さずに、将来的にはこれらをmod foo;に拡張することができます。

ねえ！ これはRFC1636ドキュメント監査です。 これは、RFC 1636が受け入れられて以来、安定した最初の主要な機能であり、この場合は、それに従うようにうまくやる必要があります。

RFCは次のように述べています。

機能を安定させる前に、機能は次のように文書化されます。

• 言語機能：
  
  
  
  • Rustリファレンスに文書化する必要があります。
  
  
  • Rustプログラミング言語で文書化する必要があります。
  
  
  • Rust byExampleに記載されている場合があります。
  
  
• 言語機能と標準ライブラリの変更の両方に以下を含める必要があります。
  
  
  
  • 変更ログの1行
  
  
  • 長い形式のリリース発表のより長い要約。
  
  

このための正しいプロセスは何ですか？ この問題のトップコメントにチェックリスト項目を追加する必要がありますか、それともドキュメントを追跡するための新しい問題を作成する必要がありますか？ 1.15リリースまでに、これらの要件を満たすドキュメントをツリーに含める必要があるように思われます。

cc @ rust-lang / docs

ありがとう@withoutboats ！ ええ、それは最初の主要なものです。 私は今朝見るためにこれを私のリストに持っていました、そして見よ、あなたはそれに私を打ち負かしました😄

これについての私の想像は常に、安定化の決定と実際の安定化は別々であるということでした。 つまり、@ rust-lang / langは「これを安定させることができます」と言うことができますが、ゲートを削除するコミットにより、ドキュメントが確実に存在するようになります。 不安定な本が存在する世界で

リリースがあったばかりなので、私の計画は次のようなことをすることでした。

1. これがFCPを離れるのを待つ
2. いくつかのドキュメントを上陸させます。 （この場合、私はそれらを書くことを計画していました）
3. 安定化PRを行います。

おそらく2つと3つを組み合わせます。

/ cc @ rust-lang / core、これはチーム間の問題であるため。

@steveklabnikは私には良さそうですが、いつでも（FCPの終了前でも）ドキュメントを上陸させても大丈夫です。 ここでのFCPは、誤って入力するのに長い時間がかかったため、とにかく疑似終了のようなものです。

また、1.15ベータブランチへの安全なバックポートを確保できるように、これらをすばやく取得することもできます。

私がこれを最初にヒットした場合、それはそれほど悪いことではありませんが、既知のバグの下に含めましょう：カスタム派生を使用して構造内で型マクロを使用すると、ICEhttps ：//github.com/rust-lang/が発生し

https://github.com/rust-lang/rust/pull/38737は、タイプマクロICE： heart：を修正します

proc_macroクレートのドキュメントに関する＃38749を作成しました。

Macros 1.1が1.15で安定することを何度も読みましたが、1.15.0-beta.1は2週間前に出荷され、少なくともextern crate proc_macro;は、夜間の4ecc85beb2016と同様に機能ゲートされています。 -12-28。 安定化の変更をバックポートする計画はありますか？

@SimonSapinはい、それは計画でしたが、それを実現する必要があります！

それはまだ計画です：p

ユーザーが#[derive(Foo)] #[foo_def = "definition.json"] struct MyStruct;書き込んだ場合、マクロハンドラーは「現在のディレクトリ」が何であるかを知る方法がないため、 definition.json見つけることができません。

これは設計によるものであるため、修正するのは簡単ではありません。とにかくこれを修正するには遅すぎると思います。

Span -> FileMap ->ファイル名->ディレクトリに移動できます。 不足しているのは、 proc_macro介して情報にアクセスすることだけです。

また、 definition.json依存関係を追加して、ビルドが変更された場合にダーティになるようにコンパイラーに指示する必要があります。

procマクロは、 env::var("CARGO_MANIFEST_DIR")を使用して、マクロ呼び出しを含むクレートのCargo.tomlを含むディレクトリを取得できます。 おそらくfoo_defはそれに関連しています。 https://github.com/dtolnay/syn/issues/70#issuecomment-268895281を参照して

@tomakaは、 変更することで実行できます。たとえば、これはinclude_str!マクロが実行する方法です。

おそらくfoo_defはそれに関連しています。

Cargo.tomlを基準にしてパスを配置する必要があるのはあまり直感的ではないと思います。

これは、FileMapを変更することで実行できます。たとえば、これがinclude_strの方法です。 マクロはそれを行います。

ええ、私はそれができることを知っています、それは現在の手続き型マクロAPIではできないだけです。

パラメータはItemです。 そのアイテムからスパンを取得するメソッドを追加することは許容されますが、依存関係を追加するようコンパイラーに要求するメソッドをItemに追加すると、ハックIMOになります。

Span-> FileMap-> filename-> directoryに移動できます。

これらのAPI（特にFileMap ）は安定化されるパス上にありますか？

それらはそうである必要はありません、実際、私は内部のどれも安定させたくありません。 代わりに、 Spanに関する情報（行、列、ファイル名など）を抽出するAPIを安定させることができます。

私はちょうど私の箱でこのエラーを受け取りました。 どうしたの？

`` error: Cannot use ＃！[feature（proc_macro）] and ＃！[feature（custom_attribute）]同時に
「」

@alexreg #[derive]を使用している場合、現在は安定しています。 #![feature(proc_macro)]は必要ありません。

@alexreg
proc_macro_derive （マクロ1.1）が安定しました。 #![feature(proc_macro)]削除するだけです。

#[proc_macro_attribute]は最近、 #![feature(proc_macro)]機能ゲートの後ろに着陸しました。 これらは#![feature(custom_attribute)]と互換性がありません。 #![feature(custom_attribute)]は、交換品が着陸すると非推奨になります（https://github.com/rust-lang/rfcs/pull/1755）。

@jseyfried proc_macroの追跡の問題はクローズされており、関連情報が含まれていないため、変更する必要があると思います。

みんなありがとう。 それは理にかなっている。

@abonanderええ、 #![feature(proc_macro)]は間違いなく＃38356を指しているはずです-＃38842を確認するときに確認する必要があります。 PRを提出してもらえますか？