cc @nrc @jseyfried

#[proc_macro_attribute]がすぐに実装されることを望んでいます。 コンパイラのサポートがまだないことに気付く前に、プロトタイプとテストの使用法をすでに持っています：unamused ::

プロトタイプ： https ：
例/テスト： https ：

タスク

（dtolnay編集：チェックリストをOPに移動しました）

cc @nrc @petrochenkov @durka @Ralith

@jseyfriedレガシーマクロと同じ名前の属性が同じスコープにインポートされた場合、属性を使用しようとすると、マクロを属性として使用できないというエラーがスローされるという問題が発生しました。 両方が同じスコープ内にあり、意図したとおりに使用できるように、この作業を行うことはできますか？

@abonanderすべてのマクロ（bang、attribute、および

パーティーに遅れてすみません。 ASTではなくトークンを公開する方向性には満足していますが、RFCで提案されている特定のTokenStream APIについて懸念があります。

pub enum TokenKind {
    Sequence(Delimiter, TokenStream),

    // The content of the comment can be found from the span.
    Comment(CommentKind),

    // `text` is the string contents, not including delimiters. It would be nice
    // to avoid an allocation in the common case that the string is in the
    // source code. We might be able to use `&'codemap str` or something.
    // `raw_markers` is for the count of `#`s if the string is a raw string. If
    // the string is not raw, then it will be `None`.
    String { text: Symbol, raw_markers: Option<usize>, kind: StringKind },

    // char literal, span includes the `'` delimiters.
    Char(char),

    // These tokens are treated specially since they are used for macro
    // expansion or delimiting items.
    Exclamation,  // `!`
    Dollar,       // `$`
    // Not actually sure if we need this or if semicolons can be treated like
    // other punctuation.
    Semicolon,    // `;`
    Eof,          // Do we need this?

    // Word is defined by Unicode Standard Annex 31 -
    // [Unicode Identifier and Pattern Syntax](http://unicode.org/reports/tr31/)
    Word(Symbol),
    Punctuation(char),
}

pub enum StringKind {
    Regular,
    Byte,
}

このAPIが、RFCがマージされたときに受け入れられた完全な計画として意図されたのか、それとも後で解決される単なる例として意図されたのかは明らかではありません。

一般に、これは、マクロ以外でコンパイラーが受け入れる「通常の」Rust構文とはかけ離れているようです。 一部のマクロはアドホックドメイン固有言語を解析したいのに対し、他のマクロは「実際のRust」構文を解析してそれを理解したいでしょう。

1. （マイナー） Eofは必要ないと思います。 Iteratorは、おそらくTokenStreamを反復処理するために使用され、 Iterator::nextすでにNoneを返し、反復の終了を通知します。

2. （マイナー） Exclamation 、 Dollar 、またはSemicolonは必要ないと思います。 たとえば、 Punctuation('!')でのマッチングはそれほど難しくありません。

3. （マイナー）RFC PRで他の人が言及しているように、doc-commentsではないコメントを省略したい場合があります。 （コメントを保持したいユースケースは、空白も保持したい可能性があります。）

4. 私が知る限り、複数文字の演算子（おそらくそれぞれが単一のトークンである必要があります）をどうするかは未解決の問題です。 考えられる解決策はPRコメントで説明されていますが、RFCテキストには含まれていないようです。

5. 数値リテラルがありません。 マクロは、リテラルを評価するために[Punct('1'), Punct('_'), Punct('2'), Punct('3'), Punct('4'), Punct('.'), Punct('5'), Punct('e'), Punct('6')]を単独で解析することになっていますか？ 受け入れる構文はRustリテラル構文（たとえば、途中に_を含めることができる）と同じではないため、 str::parse::<f32>を使用してそれを行うことさえできません。

   ここには安定性の懸念があると思います。 u128 / i128 （そしておそらく将来的にはf128 、 u256 、…）のような新しい数値型とそのリテラルを、変更を壊すことなく導入できますか？トークンAPI？ これを可能にする1つの方法は次のとおりです。

   struct IntegerLiteral { negative: bool, decimal_digits: String, type_suffix: Option<String> }
   impl TryInto<u32> IntegerLiteral { type Err = OutOfRange; /* … */ }
   // Other impls for integer types supported in this compiler version
   
   // Something similarly for floats
   

   または多分何か他のもの。 しかし、「数字が存在しないふりをする」というのは良い方法ではないと思います。

6. // WordはUnicodeStandard Annex31で定義されています-

   この定義は、それよりも正確である必要があります。 UAX 31は、識別子構文のいくつかの異なるバリエーションを指定しており、それらのいずれも「単語」とは呼ばれていません。 しかし、必要な正確なバリエーションを選択することが、現時点で非ASCII識別子が機能ゲートされている理由です。

   代わりに、これは「現在のコンパイラが識別子またはキーワードとして受け入れるものは何でも」（＃28979ごとに変更される可能性があります）として定義する必要があると思います。 たぶん、libmacroのpub fn is_identifier(&str) -> boolパブリックAPIを使用します。

7. Unicode文字列とバイト文字列リテラルは単一のトークンバリアントを共有しますが、それらの値のメモリ表現には異なるタイプがあるため、これは間違っていると思います（ strと[u8] ）。 また、 text: Symbolコンポーネントが、ソースコードのリテラルスライスであるのか、バックスラッシュエスケープを解決した後の値であるのかは明確ではありません。 間違いなく後者のはずだと思います。 （比較のために、 Char(char) \u{A0}は文字通り表すために複数のcharを必要とするため、 Char(char)は後者である必要があります。）

高レベルのマクロを作成する別の方法は、マクロのようなlispを使用することですが、これには、rustast全体のS式表現が必要になります。

@SimonSapin 、

他の人がRFCPRで言及しているように、doc-commentsではないコメントを省略したい場合があります。 （コメントを保持したいユースケースは、空白も保持したい可能性があります。）

しないでください。 構文にコメントを使用したい（保存はしませんが、代わりに別のコンパイル製品に書き込まれる）ユースケースがあります。

具体的には、別のソースファイルから文字列の翻訳をロードする翻訳マクロを作成し、デバッグビルドで副産物として翻訳される文字列のリストを生成したいと思います。 そして、そのリストに出力されるコメントを含める方法が必要です（rust-locale / rust-locale＃19）。 したがって、コメント構文を使用することは理にかなっており、マクロはそれらを参照する必要があります。

私はその投稿の他の点に同意します。

@ jan-hudec
TokenKind::Commentがなかったとしても、連続するトークン間のスパンの内容を確認することで、コメントを使用できます。

ユーザーがセマンティクスの変更を心配せずにマクロ呼び出しにコメントを自由に追加できるように、手続き型マクロがコメントを無視するように促すためにTokenKind::Commentを用意するべきではないと思います。

@ jan-hudec属性がソリューションで機能しない理由はありますか？

@abonander 、属性は絶対に意味がありません。 翻訳可能な文字列は、アイテムとしてではなく、リテラルとして機能します。 ただし、コンパイル中にそれらを抽出するのは便宜上です。これは常に個別の解析として実行できます（実際、クレート内でそれらのすべてを確認する必要があり、インクリメンタルコンパイルではそれが失敗するため、最終的にはそうなる可能性があります）。

serdeの派生に基づく手続き型マクロを作成したいのですが（したがって、serdeトークンストリーム関数を直接呼び出します）、手続き型マクロではなくライブラリとしてserde派生を利用したいと言う方法はありません。 これはマクロを導出するためだけのものではありません。「通常の」手続き型マクロにも同様のことが求められていることがわかります。

私の現在の唯一の解決策は、serde_deriveをフォークすることのようです。

問題は、rustcからの次のエラーメッセージです。

error: the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type

それを削除して機能させるのは簡単ですが、解決方法がわからない複雑さもあります-手続き型マクロクレートは、別の手続き型マクロクレートから派生したproc-macroと、関数を呼び出して、ダウンストリームユーザーの派生を生成します。 それはどのように見えるでしょうか？ 消費しているクレートの要求に応じて、クレートを2つの異なる方法でリンクできる、現時点でこのような類似のものはありますか？

@aidanhs

手続き型マクロクレートは、別の手続き型マクロクレートから派生したproc-macroを使用することと、ダウンストリームユーザーの派生を生成する関数を呼び出すことの両方を行う可能性があります。 それはどのように見えるでしょうか？

proc-macroクレートから関数（または手続き型マクロ以外のもの）にアクセスすることはできません。 TokenStream -> TokenStream関数と対応する手続き型マクロを使用する場合は、 TokenStream -> TokenStream関数を別の非proc-macroクレートに配置する必要があります。これらの関数に委任するだけのproc-macroクレート。

このRFCは、＃40939がリリースされるとほとんど実装されます。

proc_macro作成者が、マクロユーザーがクレートルートにextern crate foo;を含める必要なしに、事前に定義されたクレートfooアイテムを使用する拡張を作成する方法を提供します

非マクロアイテムと、そのアイテムを参照する手続き型マクロの両方を含む単一のクレートを提示するとします。 ＃40939が着陸したとき、この3つの木枠のパターンは、この目標を達成するための慣用的な方法になりますか？

1. すべての非マクロアイテムをfoo_runtime
2. 必要に応じてfoo_runtimeのシンボルを参照しながら、 foo_macrosに手続き型マクロを実装します
3. foo_runtimeとfoo_macrosのアイテムをpub useにする最後の「ファサード」クレートfooを追加します
   
   
   
   • これは、ユーザーが直接インポートする唯一のクレートです
   
   
   • これは、衛生システムがマクロを修正して正しいクレートを指すようにするために機能します
   
   

私のユースケースでは2つの木枠をつだけで済ませることができれば、使い勝手が良くなると思います。

@lfairy 「2つの木枠」のパターンは慣用的な方法になると思います。

1. マクロ以外のすべてのアイテムをfoo
2. 必要に応じてfooシンボルを参照して、 foo_macrosに手続き型マクロを実装します。

#[proc_macro]
fn m(_: TokenStream) -> TokenStream {
    quote! {
        extern crate foo; // due to hygiene, this is never a conflict error
        foo::f();
        // --- or just --- (if/when we get the sugar)
        $universe::foo::f();
    }
}

1. pub useからアイテムfoo_macrosでfoo 。

これは、衛生システムがマクロを修正して正しいクレートを指すようにするために機能します

別のクレートで手続き型マクロを再エクスポートしても、手続き型マクロの名前がどのように解決されるかには影響しません。

@jseyfried ：この再

@ colin-kiegel
カスタム派生クレートは、たまたま#[proc_macro_derive]しか持たないprocマクロクレートです。
#[feature(proc_macro)] 、他のprocマクロを再エクスポートできるのと同じように、通常のクレートでカスタム派生を再エクスポートできます。

@jseyfried現時点での状況は承知しておりますが、理想とは思えないので質問を投げかけ、話し合いたいと思いました。 あなたが説明する状況では、別のクレートの手続き型マクロに「委任」/再利用することは、マクロの作成者（この場合はserde）に手続き型マクロを2つのクレートに分割するように説得することの問題になります。 通常の関数のように手続き型マクロを呼び出すことができれば、上流のクレート作成者は、私がクレートを使用していることを知る必要さえありません。

とはいえ、互換性の危険性を認識しています-マクロによって生成された正確なトークンツリーは安定したインターフェイスの一部になるため、serdeがパッチバージョンでDeriveを生成する方法を変更し、壊れやすいマクロを作成した場合、マクロは、私のクレートのすべての新規ユーザーに対して壊れます（現在の場合の壊れやすいマクロとは対照的に、最悪の場合、特定の入力に対してのみ機能しますが、一貫して機能します）。

@jseyfried

これは現在の貨物デプリストからfooを引き出しますか？ それは悪いことのように聞こえます（つまり、現在のバイナリにリンクされているfooという名前のクレートが2つある場合、特に愚かなことをしますか？）。

@aidanhsこれは、独自のRFCを保証する主要な言語の変更/追加になります。

@ arielb1

これは現在の貨物デプリストからfooを引き出しますか？ それは悪いですね

ええ-悲しいことに、引用されたextern crate名前は衛生的ではありません。つまり、解決策は、手続き型マクロが使用されるスコープ内にあるクレート名によって異なります。 再エクスポートのトリックを使用してこれを軽減することはできますが（つまり、 fooがスコープ内にあることがわかるようにfoo foo_macrosを再エクスポートする）、それは保護されませんfooという名前のクレートが2つある場合の、あいまいさのエラーに対して。

ここでの最善の解決策は、 --target-externコマンドライン引数を使用して、フェーズ1（つまり、ターゲットwrtホストとターゲット）の依存関係をproc-macroクレートのCargo.tomlに追加することだと思います。 これにより、 quote!内のスコープ内のextern crate名を明示的にリストできます。

@jseyfried

アイデアは、proc-macroクレートがその「ターゲット」メタデータに依存関係を持つということですよね？

@ arielb1ええ、その通りです。

このRFCは、＃40939がリリースされるとほとんど実装されます。

@jseyfriedのように、そのPRが着陸したときに安定する準備はできていますか？ そうでない場合、安定化をブロックし続けるものは何ですか？ 私はこれが、実装に向けて95％の道のりを歩み、人々がすべて興奮し、その後物事が反抗的に衰退するような、さらに別の機能にしたくありません。

のように、そのPRが着陸したときに安定する準備はできていますか？

いいえ、 extern crate名前を安定させ、将来的には衛生状態を保証する前に、APIの経験を積みたいと考えています（つまり、 @ arielb1が指摘したこの問題に対処します）。

このAPIに重大な変更を加えたいと思うでしょう。 @eddybは、すべてのトークンツリーにOpKindを一般化することを提案/検討しました。 また、ドキュメントコメントや浮動小数点リテラルなどの処理方法を変更する可能性があります。全体として、このPRのAPIは、安定化を検討するのに十分なほど成熟していません。

@bstrie悲しいことに、派生マクロ安定化が失敗したように、procマクロ安定化を高速化するRFC（たとえば、トークンストリームは文字列表現を介してのみアクセスできる限られたAPIを使用）： https ：

@ est31延期、もっと似ています-このAPIを少し経験した後、安定化への早道に同意できるサブセットに同意するかもしれません。

StringベースのAPIは、宣言型マクロ2.0との相互作用が悪く、マクロ2.0がなく、 #[derive]だけでも、今日すでに制限されています。 人々がマクロ2.0に移行する際の問題を回避するために、 StringベースのAPIの急増を可能な限り回避したいと考えています。

#[proc_macro_attribute]がトレイトメソッドで拡張されていないように見える問題を

これがproc_macroクレートとその新しいAPIの追跡の問題であるため、私もいくつかの考えを書き留めると思いました。 proc-macro2というクレートを公開しました。これは、安定したRustでコンパイルする機能を提供することを除いて、ツリー内のproc_macroクレートとまったく同じにすることを目的としています。 また、機能を使用して夜間のRustでコンパイルし、より良いスパン情報を利用することもできます。 そのライブラリは、 synような他のライブラリの基盤となることを目的としており、 synの開発で、 proc_macro直接対処したいいくつかの欠点を見つけました。

• いくつかの種類のリテラル用のLiteralコンストラクターはありません。 これは、文字列化とそれに続く構文解析によって回避されますが、文字列APIを経由せずにこれらを直接構築できると便利です。
  
  
  
  • 生の文字列- r###" foo "###
  
  
  • 生のバイト文字列- rb#" foo "#
  
  
  • バイトリテラル- b'x'
  
  
  • ドキュメントコメント-これらは現在Literalトークンとして表されています。
  
  
• Literalを調べて、その値を抽出する方法はありません。 現在、リテラル拡張クレートを使用してリテラルをto_string再解析していますが、理論的には、この情報はすでにLiteral格納されているため、次のことができると便利です。アクセスします。
• 場合によっては、トークンのマッピングは少し奇妙に解釈される可能性があります。 つまり、現在、ドキュメントコメントはLiteralタイプにマップされています。

それ以来、ここから

#[proc_macro_derive(foo, attributes(foo))]を持つカスタム派生に影響する#![feature(proc_macro)]でテストしたときに、破損が発生しました。 つまり、カスタム派生と同じ属性の名前を持つカスタム派生です。 そのようなクレートの1つは、 #[derive(error_chain)] #[error_chain(...)] struct ErrorKind { ... }を持つmine-derive-error-chainです。 もう1つはderive-newで、これには#[derive(new)] #[new] struct S;ます。 他にあるかわかりません。

このようなコードの場合、コンパイラは2番目の属性で"foo" is a derive mode文句を言います。 これは意図的なものですか、それとも修正できますか？ 意図的にカスタム派生の名前をErrorChainなどに変更する準備をする必要があります。

@Arnavion
これは一般的に意図的なものproc_macro_attribute派生する前にnewがproc_macro_attribute場合、展開はあいまいになります。 newをproc_macro_deriveにすることは特に可能ですが、それだけの価値があるかどうかはわかりません（将来の互換性の危険性もあります）。

これは一般的に意図的なものproc_macro_attributes派生する前にnewがproc_macro_attribute場合、展開はあいまいになります。

さて、 #[derive(error_chain)]名前を#[derive(ErrorChain)]ます。

newをproc_macro_deriveにすることは特に可能ですが、それだけの価値があるかどうかはわかりません（将来の互換性の危険性もあります）。

確かに、私はnewを特別なケースにすることを求めていませんでした。 これは、私が知っている2つのproc_macro_deriveのうちの1つからの単なる例であり、これによって壊れています。

私は平均特殊なケースではありませんでした- @Arnavion申し訳ありませんが、私の最後のコメントは最も明確ではなかったnew特になく、できるように#[derive(some_macro)] #[some_attr] struct S;ときsome_attrに解決さproc_macro_derive 。 some_attrがproc_macro_attributeに解決される場合、これはあいまいなエラーである必要があります。 今日、 some_attrがいずれかのマクロに解決されると、あいまいなエラーになります。

よし、分った。

（これがこのような質問に適した場所であることを願っています。 ）

これの状況はどうですか？

• [] proc_macro作成者が、マクロユーザーがクレートルートにextern crate foo;を含める必要なしに、事前に定義されたクレートfooアイテムを使用する拡張を作成する方法を提供します（PR＃40939 ）。

PRは着陸しましたが、ボックスはまだチェックされていません。 @jseyfriedはここで何かについて言及しましうまくいくようです。 ただし、 useではまったく機能しないようです。

let call_site_self = TokenTree {
    kind: TokenNode::Term(Term::intern("self")),
    span: Span::call_site(),
};
quote! {
    extern crate foo; // due to hygiene, this is never a conflict error

    // Neither of those works    
    use foo::f;
    use self::foo::f;
    use $call_site_self::foo:f;
}

私は何かが足りないのですか？ マクロにインポートされた外部クレートからuseシンボルへの慣用的な方法は何ですか？

useは使用できません。https：//github.com/rust-lang/rfcs/issues/959を参照して

@parchedこの他の問題をリンクしていただきありがとうございます。 私のユースケースは次のとおりです。

私のマクロでは、ユーザーにマッチマッチャーに似たものを書かせたいと思っています。 具体的には、ユーザが書き込んTerm 、これはどちらかの照合値をバインドする列挙型または単純な変数名の変異体であってもよいです。 macro_rules!構文で擬似コードを書くには：

macro_rules foo {
    ($matcher:ident) => {
        match something() {
            $matcher => {}
            _ => {}
        }
    }
}

ここで、ユーザーが列挙型名なしでバリアント名use my_crate::AnEnum::*;ステートメントを挿入します。 しかし、これは（現時点では）不可能なので、 $matcherが列挙型のバリアントであるかどうかを自分で確認する必要があります。

私の説明が理解できることを願っています。 マクロで生成されたコードでuse別のユースケースを示したかっただけです。

@LukasKalbertodtはあなただけ使用することができますmy_crate::AnEnum::$matcher => {}にmatch ？
気にしないでください、私はあなたの問題です-そのためにはhttps://github.com/rust-lang/rfcs/issues/959が必要になると思います。

@jseyfriedいいえ： $matcherは、バリアント名（この場合、ソリューションは機能します）またはmatch x { simple_var_name => {} }ような単純な変数名のいずれかです。 後者の場合、AFAICTは機能しません。 （ところで、 useが重要であることを示すために、別のユースケースについて言及したかっただけです）

@jseyfried

これは一般的に意図的なものproc_macro_attributes派生する前にnewがproc_macro_attribute場合、展開はあいまいになります。

さて、 #[derive(error_chain)]名前を#[derive(ErrorChain)]ます。

カスタム派生の属性も、インポート順序に基づいてカスタム派生が行うようにオーバーライドするのではなく、 macro_rulesマクロと競合するようです。 つまり、このコードは次のようにコンパイルされます。

#![feature(proc_macro)]
#[macro_use] extern crate error_chain; // macro_rules! error_chain
#[macro_use] extern crate derive_error_chain; // #[proc_macro_derive(error_chain, attributes(error_chain))]

#[derive(error_chain)] // No error. Resolves to custom derive
enum ErrorKind {
    /*#[error_chain]*/ // (1) As discussed above, can't use this any more since it conflicts with the name of the custom derive
    Foo,
}

これは、 (1)が安定して動作することを除いて、現在の安定したRustの動作と一致します。 私も明示的に使用したいユーザーがいることを文書化してきました#[macro_use]してerror-chainクレートをインポートする前にそれをインポートする必要がありますderive-error-chain 。

しかし、カスタム派生の名前をErrorChainして、 (1)をproc_macro機能（安定したコードの1つの重大な変更）で機能させる場合でも、次のようになります。

#![feature(proc_macro)]
#[macro_use] extern crate error_chain; // macro_rules! error_chain
#[macro_use] extern crate derive_error_chain; // #[proc_macro_derive(ErrorChain, attributes(error_chain))]

#[derive(ErrorChain)] // Unique name, so no error
enum ErrorKind {
    #[error_chain] // (2)
    Foo,
}

それでもコンパイルされません- (2)の属性は、エラーを生成します： macro_rulesマクロは、次のようにオーバーライドされるのではなく、カスタム派生によって登録された属性と明らかに競合するため、 macro `error_chain` may not be used in attributes最初のケースでは。

したがって、カスタム派生とその属性の両方の名前を変更する必要がmacro_rulesマクロの名前を再利用しています）が、これはカスタム派生が安定したので、半年後には問題になると思う理由はありませんでした。

カスタム派生物自体がmacro_rulesマクロをオーバーライドするのと同じように、カスタム派生物の属性がmacro_rulesマクロをオーバーライドするように作成できますか？ 実際、それらの間にあいまいさがどのようにあるかはわかりませんが、同じ名前のカスタム派生の後にmacro_rulesマクロがインポートされた場合と同じ理由であると思います-すべてのマクロがマクロの種類を考慮せずに同じ名前空間。

procマクロについて話すためのあまり正式ではない「場所」はありますか？ #rust-proc-macro IRCチャンネルのように？ この機能について時々小さな質問をしたいのですが、このスレッドをスパムするのは間違っていると感じています：see_no_evil：そして#rustチャネルでは、ほとんどの人がproc-macrosと特に新しいproc_macro API（不安定ですべてのため）。 だから：このトピックをどこで議論するかについて何か考えはありますか？

@LukasKalbertodt #rust-internals 、多分、または/ r / rustで新しいスレッドを開始します。

TokenStream::from_strは、手続き型マクロの外部（ビルドスクリプトなど）で使用するとパニックになります。

thread 'main' panicked at 'proc_macro::__internal::with_sess() called before set_parse_sess()!', /checkout/src/libproc_macro/lib.rs:758:8

このパニックを暗黙的にダミーの「セッション」を作成することで置き換えることは可能/望ましいでしょうか？ または、パブリックAPI（安定化へのパスを含む）を追加して作成しますか？

他のシステムのマクロに関する文献を見た人はいますか？ これについての皆さんのご意見をお聞かせください。 ここでSchemeについて説明します。これは、私が最もよく知っていることだからです。

私は自分のプロジェクトでR7RSスキームのsyntax-rules実装に個人的に取り組んでおり、 syntax-caseが非衛生的および衛生的マクロシステム（ defmacro両方をサポートするための基礎を形成できることを発見しました。およびsyntax-rules ）。 GNUGuileはこれを行います。 syntax-caseは、構文オブジェクトリスト（またはSchemeのTokenStreamの行の中の何か）で追加の述語検証を実行できるフェンダーもサポートしています。 Markが作業中であり、スコープのセットとしてのバインディングに触発されているように見えます。

また、コンパイル時の任意の計算をサポートする必要があるかどうかについても説明する必要がありますか？ Racketは実際には、物事に対して全体的な「フェーズ」アプローチを採用しており、 begin-for-syntaxすると、マクロ展開中のコンパイル時レベルでの定義と計算（？）が可能になります。 。

Schemeの(datum->syntax <thing-to-copy-scope-from> <thing-to-apply-scope-to>)すると、衛生状態を制御できます。これにより、マクロのスコープをエスケープし、代わりに、直接のスコープ外のオブジェクトのスコープを取得できます。

この例は、Schemeプログラミング言語、第3版からhttp ： (include "filename.scm")をsyntax-caseマクロとして示しており、インタープリターがマクロを使用して、ファイルから読み取り、評価を続行するようにランタイムを設定できるようにしています。 ここでのより深い質問は、マクロマクロシステムがマクロ拡張時にそのようなことを実行できるようにし、ファイルインポートのトリガーなどのコンパイル時の計算をトリガーするかどうかです（ただし、これは直接コンパイラ機能で発生するようですが、だから多分私たちはこれをしたくないでしょう）。

マクロの限界はどうあるべきですか？ Rustは、コンパイル時間を短縮したいので、コンパイル時の評価を制限したい（そして特に無限ループを避けたい）と思います。 Racketは、Lisp in Small Piecesで参照されているように、フェーズを使用して「作成者と拡張機能のタワー」アプローチを採用しています。 コンパイル時APIへのアクセスを許可して、ファイルI / Oや制限付きの再帰計算を実行できるようにしますか？ 手続き型マクロがCSVスプレッドシートの仕様をswitchステートメントに変換できるようにする必要がありますか？

他のシステムについて聞いてみたいです！ テンプレートHaskellには、ASTを表すために明確に定義された型を使用した興味深いアプローチがあり、Haskellの怠惰は、制御構造のマクロの多くの使用に取って代わることができると聞きました。

私がラインから外れている場合は申し訳ありません。

マクロの限界はどうあるべきですか？

この号で説明されている手続き型マクロの場合、なし。 手続き型マクロはコンパイラの拡張機能です。 少しのC ++コードを取り、それをclangで実行し、結果のオブジェクトをコンパイルに追加することができます。 SQLが必要で、データベースにクエリを実行して対応する結果タイプを見つけ、適切な結果セットを生成することができます。 これらは、人々がやりたい実際のユースケースです。

Rustには別のマクロシステムがあることに注意してください。 この更新はRFC1584として承認されており、実装はhttps://github.com/rust-lang/rust/issues/39412によって追跡されてい

@ VermillionAzure 、参照したスキームフォームを

macro_rules 、およびRFC 1584にsyntax-rules似ています。 それらを強化するための提案がある場合は、 https：//github.com/rust-lang/rust/issues/39412がおそらくそれについて議論するのに最適な場所です。

この問題の対象となるproc-macrosは、 define-syntaxの一般的な形式に似ています。 そして、このRFC（ 1566 ）は、 syntax-caseようなものを非常に意図的に定義していません。 トークンストリームを変換する関数を呼び出すためのインターフェイスのみ。

インターフェイスは、 syntax-caseようなものを別のクレート（ライブラリ）に実装できるように定義されており、そのようにすることを目的としています。 気になる方は、お気軽に遊んでみてください。 APIの使用がいかに簡単か、または難しいかについてのプロトタイプとレポートの両方を歓迎します。

アイデアは、lispのように関数のようにマクロを定義することでしたが、 macro_rules!定義するマクロを返すマクロを持つことだったと思います。

したがって、以下は同等です。

    macro_rules! foo {/*define macro here*/}

#[proc_macro]
pub fn foo(tokens: TokenStream) -> TokenStream {
    macro_case! tokens {/*define macro here*/} //takes `tokens` as first argument, returns a `TokenStream`
}

これが、 syntax-rulesとsyntax-caseがスキームで機能しているように見える方法です。

@VermillionAzure
これ、あなたが欲しいものですか？

@ porky11いいえ、そうではないようです。 私はSchemeマクロが議論に追加するのに適切なアイデアであるかどうかを見たかっただけです-手続き型マクロはSchemeのsyntax-caseマクロシステムよりもはるかに強力であることが意図されているので、それは些細なことですここで提供される任意のパワーの観点から、すべてのマクロシステムを実装します。

@ jan-hudecいかなる種類のセキュリティ保証もなしに、コンパイラ拡張として任意の計算を許可するのは賢明ですか？ 私はここで手続き型マクロが非常に強力になるという考えに完全に床を張っていますが、Rustの潜在的なユーザーはこれをパッケージを使用することの欠点と見なしますか？ 私は決してセキュリティの専門家ではありませんが、コンパイラ拡張機能内で使用されるライブラリの脆弱性を簡単に使用して、Rustコンパイラを攻撃ベクトルに悪意を持って変えることができませんでしたか？ さらに、手続き型マクロで使用されるライブラリにバグが発生した場合（たとえば、不正なCライブラリコードによってトリガーされたsegfault）、これはsegfaultがトリクルアップし、適切なエラーメッセージなしでコンパイラが失敗することを意味しますか？

手続き型マクロで発生するエラーを、コンパイラの他の部分に影響を与えない方法でカプセル化する方法はありますか？

別のアイデア：手続き型マクロはいつ実行されますか？ 手続き型マクロが、関連する可能性のある副作用（たとえば、ステートフルな外部サーバーとの通信、外部SQLデータベースの変更、外部システムにログを記録するためのセキュリティキーの取得）を持つコードと対話できる場合、それは手続き型マクロがコンパイルプロセスによってトリガーされる順序は重要ですか？

@VermillionAzure Cargoパッケージには、コンパイル時に任意のコードを実行するビルドスクリプトがすでに含まれている可能性があるため、手続き型マクロはその面で事態を悪化させることはありません。依存関係を信頼する必要があります。 （これは、crates.ioが不変/追加のみであり、 Cargo.lockファイルがある場合、依存関係が自動的に更新されないため、多少簡単になります。特定のバージョンのみを信頼する必要があります。）ビルドスクリプトが信頼しなかった場合でも存在する場合でも、依存関係は実行時に任意のコードを実行できます。 コンパイル時ははるかに悪いですか？

この議論は、私に関連しているが異なる問題について考えさせます。

クレートが2つのprocマクロを定義するとします。 foo!()は一時ファイルを書き込み、 bar!()は同じファイルを読み取ります。 このクレートのコンシューマーは、同じモジュールでfoo!()とbar!()両方を呼び出します。 次に、コンパイルが成功するかどうかは、 foo!()とbar!()どちらが最初に展開されるかによって異なります。 この順序は実装によって定義されており、十分な数の人がこのようなコードを作成すると、デファクトスタンダードになる可能性があります。

しかし、これがどれほどの問題であるかはわかりません。 これが構造体の順序体の順序体の繰り返しにつながるかどうかだけが心配です。

@SimonSapin

私はあなたの立場に同意しますが、コンパイル時の実行と実行時の実行には1つの重要な違いがあることを指摘しておく必要があります。

物事は一度コンパイルされてから多くのマシンにデプロイされる傾向があるため、これは異なる脅威モデルを提供します。 （例：Linuxディストリビューションビルドクラスターでのメンテナの不注意とサンドボックスの欠点の悪用。）

@lfairyはい、これはRacketが10年以上前に2002年に抱えていた正確な問題です「Composable and Compilable Macros：You Want it When？ 」という論文を作成しました「R6RSライブラリの暗黙的なフェーズ」でライブラリ/モジュールの評価のフェーズに関する論文も書いています。

@SimonSapinコンパイル時は、さらに悪化する可能性があります。 コンパイラがランダムにクラッシュしたり、コンパイラによってトリガーされた悪意のある動作を実行したりすると、誰かが「Rustのモジュールは本質的に安全ではない」などのタイトルの巨大なReddit投稿を書くことになります。

@VermillionAzure 、私は記事をあまり注意深く読んでいませんでしたが、Rustが直面する問題はSchemeが直面する問題とは非常に異なるため、それらは議論に関連するとは思いません。

スキームでは、1つのライブラリが関数とマクロの両方を提供できるため、コンパイラは、コンパイル時に必要な関数と実行時に必要な関数を正しく分類する必要があります。 ただし、Rustでは、クレートは手続き型マクロまたはランタイム関数のいずれかを提供するため、この分割は（当面は）明らかです。

（ランタイム関数を提供するクレートは、ルールベースの（衛生的な）マクロも提供できますが、Rustではこれらは別個のメカニズムであることに注意してください）

@lfairyが話している問題は、エキスパンダー関数の実行順序の1つです。 Rustでは、コンパイルは個別のファイルに対して並列であり、増分である可能性があるため、エクスパンダの実行順序は定義されていません。 しかし、どちらの記事も実際にそれを扱っていますか？ 私はそれを見ませんでした。

@ jan-hudecええ、あなたは正しいと思います。 ただし、特定のモジュールが副作用を生成しないことを保証できない限り、コンパイル時に副作用が許可されている場合、評価の順序は間違いなく重要です。 モジュールは「入力可能」ですか？

一部の詳細（以下を参照）は信頼できないため、手続き型マクロには「おそらくないはず」の副作用があると思いますが、言語に型システムのようなメカニズムがなく、純粋に強制することはできないでしょう。機能的。

これらの詳細には、他のprocマクロと比較した実行の順序と同時実行性、およびproc-macroがインクリメンタルビルドで再実行されるかどうかが含まれます。 後者の場合、ビルドスクリプトでrerun-if-changedと同様の依存関係を宣言するために何かを追加したい場合があります。 また、ビルドスクリプトと同様に、これらの宣言は不完全またはバグがある可能性があります。 すべてのバグを静的に防ぐことはできません。

副作用について何も保証しないようにする必要があると思います（つまり、procマクロクレートは副作用の動作に依存することはできません。また、適用されるモジュールのコード変更以外の再トリガーに依存することもできません（したがって、グローバル状態はありません）。

後で、rerun-if-changedなどを指定する方法で、この要件を緩和できます。

（私はここでいくらか役立つ中途半端な一般的なビルドスクリプト/ procマクロセキュリティの提案を持っていますが、私はまだそれを実際に書いていません）

IMO procマクロ/カスタム派生は、I / Oやその他の外部接続なしでサンドボックス環境に配置し、miriによって、おそらくクレーンリフトJITを使用して評価する必要があります。

@ est31それはいい考えですが、ディーゼルinfer_schemaのようなものです！ すでに
存在する場合、bindgenはファイルを読み取り、プログラムを実行する必要があります。 と
env！ I / Oを使用します。

2017年11月9日06:19、「est31」 [email protected]は次のように書いています。

IMOprocマクロ/カスタム派生はサンドボックス環境に配置する必要があります
I / Oやその他の外部接続なしで、
ミリ、多分クレーンリフトJITで。

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

＃40939と＃44528はすでにマージされているようです... @ jseyfriedチェックリストを更新できますか？

@ mark-imが更新されました。

手続き型マクロは手続き型マクロを生成できますか？

@VermillionAzure試したことはありませんが、試しられなかった理由はわかりません。 もちろん、「ランタイム」コードを生成するprocマクロのように、使用されているものとは別のクレートに配置する必要があります。

synでは、今日proc_macro :: TokenNodeの制限に遭遇しました-ブロック区切り文字{ ... }は入力TokenStream内の1つのスパンにのみ関連付けられているため、トリガーする方法はありません終了}のみを指すエラー。 Rustcにはこの制限がないようです。

mod m {
    type T =
}

error: expected type, found `}`
 --> src/main.rs:3:1
  |
3 | }
  | ^

procマクロで実行できる最善のことは、ブロック内の最後のトークンを指すか、ブロック全体を指すか、ブロックの後の次のトークンを指すことです。これらはいずれも、上記のようなエラーに対して実際に必要なものではありません。

一般的な解決策は、 Span::startとSpan::endが現在のLineColumnではなく1文字のSpan返すようにしてから、 Spanからスパンの最初の行/列に移動します。

sp.begin().line // before
sp.line() // after

sp.end().line // before
sp.end().line() // after

sp.end() // after, not possible before

＃43604でそのAPIを追加@abonanderに言及。

Span :: startとSpan :: endは、現在のようにLineColumnではなく1文字のSpanを返し、SpanからSpanの最初の行/列に移動する方法を公開します。

これにより、Spanは区切りリストに必要な特別な動作を採用しますが、他のすべてのスパンでは正しくありません。 一般的には正しくありません。 ものを結合してfoo(hi)ような式のスパンを取得することを検討してください。 今、あなたはを指すようにしたいfooと取るsp.begin()が、 sp.begin()の最初の文字にのみポイントをfoo 。

より良い解決策は、 proc_macro::TokenNode::Group 2つのスパンを追加するか、任意のスパンを作成できるようにすることだと思います。

Span::begin / endリターンタイプは変更する必要があるかもしれません： https ：

Span::def_site()を取得して、手続き型マクロのスコープ内にあるものに対して問題を解決しようとしています。 これがどのように機能するのか誤解していますか？

Span::call_site()を使用し、main.rsでMySend定義している場合、ほぼ同じコードが機能します。これは、私が期待するとおりです。 ただし、 def_site()で動作させることはできません

#![feature(proc_macro)]

extern crate proc_macro;

use std::marker::Send as MySend;
use proc_macro::{TokenStream, TokenTree, TokenNode, Term, Delimiter, Span};

#[proc_macro]
pub fn impl_mysend_for(tokens: TokenStream) -> TokenStream {
    let span = Span::def_site();
    let ident = tokens.into_iter().next().unwrap();
    vec![
        TokenTree { span, kind: TokenNode::Term(Term::intern("unsafe")) },
        TokenTree { span, kind: TokenNode::Term(Term::intern("impl")) },
        TokenTree { span, kind: TokenNode::Term(Term::intern("MySend")) },
        TokenTree { span, kind: TokenNode::Term(Term::intern("for")) },
        ident,
        TokenTree { span, kind: TokenNode::Group(Delimiter::Brace, TokenStream::empty()) }
    ].into_iter().collect()
}

#![feature(proc_macro)]

extern crate mac;

struct S;
mac::impl_mysend_for!(S);

fn main() {}

error[E0405]: cannot find trait `MySend` in this scope
 --> src/main.rs:6:1
  |
6 | mac::impl_mysend_for!(S);
  | ^^^^^^^^^^^^^^^^^^^^^^^^^ did you mean `Send`?

Syn側でこれを追跡する： https ：

@dtolnay
ここでの問題は、 MySendがフェーズ0（つまり、クロスコンパイル時のホストアーキテクチャ用）でインポートされるため、フェーズ1（つまり、ターゲットアーキテクチャ用にコンパイルするとき）では使用できないことです。

ここでの解決策は、proc-macro cratesにフェーズ1（ターゲットアーキテクチャ）の依存関係を持たせて、フェーズ1のアイテムをスコープにインポートできるようにすることです。

今日、回避策は次のように戻ることです。

quote! { // n.b. non-interpolated tokens from `quote!` have `Span::def_site()`
    mod dummy {
        extern crate std;
        use self::std::marker::Send as MySend;
        unsafe impl MySend for $ident {} // this line is equivalent to what you have above
    }
} 

これを手動で作成することもできます。便宜上、 quote!を使用しています。

衛生上の理由により、 dummy / std / MySendはスコープ内の他のものと衝突することはありません。したがって、同じモジュールでこのマクロを複数回使用しても安全です。 identが「MySend」などであっても安全です。

この問題、およびmod dummyの必要性と解決策については、 https： //github.com/rust-lang/rust/issues/45934#issuecomment-344497531で詳しく説明されてい

残念ながら、フェーズ1の依存関係が実装されるまで、これは人間工学的ではありません。

ありがとう@jseyfried！ それはうまくいきます。 いくつかのフォローアップの質問：

• 私の以前のコメントのコードでは、私が変更した場合はimpl_mysend_forためIMPL生成するSendの代わりにMySendその後、すべてのコンパイルを。 これはどのSend解決され、フェーズ0とフェーズ1の区別に当てはまらないのはなぜですか？ これは意図的に機能していますか、それとも偶然ですか？

• Sendように、私のdef_site()トークンで使用できるスコープには他に何がありますか？

• MySendがライブラリから取得する必要がある場合（ serde::Serialize導出していると想像してください）、エンドユーザーはCargo.tomlにserdeが必要です。 extern crate serdeを書く必要があります。 手続き型マクロのCargo.tomlに対してdef_site() IDを使用してextern crateを作成し、ダウンストリームに対してcall_site() IDを使用してextern crateを解決することは可能でしょうか。 Cargo.toml？

外部クレートの場合、procマクロによってフェーズ1でクレートを明示的に使用できるようにする必要があると思います。

#[proc_macro_derive(Serialize, attributes(serde), crates(serde))]

@dtolnay

以前のコメントのコードで、impl_mysend_forを変更して、MySendではなくSendのimplを生成すると、すべてがコンパイルされます。 これはどの送信先に解決され、なぜフェーズ0とフェーズ1の区別に当てはまらないのですか？ これは意図的に機能していますか、それとも偶然ですか？

良い質問。 現在、プレリュードは定義サイトの範囲内にあり（proc-macro crateが#![no_implicit_prelude]ない限り）、これは（ある意味で）フェーズ0とフェーズ1の違いによる事故です。 。

ただし、人間工学の場合、フェーズ1にはproc-macroルートにstdが暗黙的に含まれている必要があり（常にquote!(use std::...);ができるように）、利便性/人間工学の前置きが含まれている必要があります。これらはすでに暗黙的であるためです。フェーズ0で。フェーズ1のルートにstdをすぐに追加するPRがあります。

Sendのように、def_site（）トークンで使用できるスコープには他に何がありますか？

上記のプレリュードと（まもなく） stdて、フェーズ1のスコープ内にある他のものは、proc-マクロ自体だけです（フェーズ0であるproc-マクロ関数ではありません）。

例えば、

#[proc_macro]
fn f(input: TokenStream) -> TokenStream { ... }

#[proc_macro]
fn g(_input: TokenStream) -> TokenStream {
    quote! {
        f!(); ::f!(); // These both resolve to the above proc macro
        f(); // This doesn't resolve since the function is in phase 0
    }
}

手続き型マクロのCargo.tomlに対してdef_site（）identを使用してextern crateを解決し、ダウンストリームのCargo.tomlに対してcall_site（）identを使用してextern crateを解決することは可能でしょうか？

はい、ただし、 Span::def_site()外部クレートは、手続き型マクロのCargo.tomlのフェーズ1（ターゲット）依存関係に対して解決されるはずです。今日のフェーズ0依存関係は、ホストプラットフォーム用にコンパイルされたライブラリにリンクされています。 。 フェーズ1の依存関係はまだ存在しないため、外部クレートの名前は非衛生的に解決されます。これは、ご指摘のとおり厄介です。

フェーズ1の依存関係ができたら、最初に各拡張でextern crateを引用する必要がないため、これはそれほど問題にはなりません。 ただし、それでも修正する必要があります。現在の計画では、最初にproc-macro crateのターゲット依存関係を解決してから、チャーンを回避するために優先度の低い警告サイクルで非衛生的な解決にフォールバックします。

外部クレートの場合、procマクロによってフェーズ1でクレートを明示的に使用できるようにする必要があると思います。
#[proc_macro_derive(Serialize, attributes(serde), crates(serde))]

興味深いことに、この方法で実装できます。

代わりに、フェーズ1のクレートがproc-macroクレートルート（例： #[phase(1)] extern crate foo; ）で宣言され、すべてのprocマクロ（例： quote!(use foo::bar); ）で自動的に使用できるようになると考えていました。 extern crateはとにかく途中であるため、フェーズ1のクレートを宣言することを完全に回避できます。Cargo.tomlからのすべてのターゲット依存関係は、フェーズ1のproc-macroクレートルートで自動的にスコープに含まれます。

私のコードでは、名前解決を制御する目的とエラーメッセージを制御する目的の2つの目的でスパンを使用しているように見えることがわかりました。 これら2つは不可分にリンクされていますか、それとも1つのスパンの名前解決の側面と別のスパンの行/列のエラーメッセージの場所を混在させるスパンを作成することは可能でしょうか？ これは一般的なニーズだと思います。

具体的には、カスタム派生のdef_site内にトレイトをスコープに入れ、ユーザーの構造体のフィールドでトレイトメソッドを呼び出したいと考えています。 フィールドタイプが正しい特性を実装していない場合は、エラーメッセージで対応する構造体フィールドに下線を付ける必要があります。

コンパイルして実行するdef_sitespanを使用してメソッド呼び出しを生成できますが、残念ながら、マクロ1.1で見たように、エラーメッセージは常に派生属性を指します。

  |
4 | #[derive(HeapSize)]
  |          ^^^^^^^^

または、構造体フィールドのidentまたはtypeと同じスパンでメソッド呼び出しを生成できます。これは、正しい下線を示していますが、def_siteのスコープ内の特性に解決できません。

  |
7 |     bad: std::thread::Thread,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^

どうすれば正しく解決して、希望どおりにエラーを表示できますか？

@dtolnayそれは素晴らしいポイントです、ありがとう。

https://github.com/rust-lang/rust/issues/46489を修正する適切な方法は、生成された#[derive(…)]トークンが同じ名前解決スパンを持つようにすることだと思います。タイプ定義としてのスコープ、およびそれらを作成したquote! {}マクロ呼び出しでのエラーメッセージスパン。

現在の衛生の話は何ですか？ 私は（4か月前に）機能していた手続き型マクロのような機能を持っていますが、rustc 1.24.0-nightly（b65f0bedd 2018-01-01）の時点で、引数がスコープ内に見つからないと文句を言います。

申し訳ありませんが、最初に課題追跡システムを検索する必要がありました。https：//github.com/rust-lang/rust/issues/46489にアクセスしたようです。

私は現在、derive（Deserialize）の正しい実装をブロックしていると思う＃47311を提出しました。 手続き型マクロは、プライベートフィールドを持つ構造体を構築できません。

self.0ような名前のないタプル構造体フィールドへのアクセスがself.xような名前の付いた構造体フィールドへのアクセスとは異なる.トークンのスパンの要件を持つ別の＃47312を提出しました。

47311と＃47312は、それぞれ＃48082と＃48083で修正されています。

上記の2つのPRがレビュー/コメントを待っています。

https://github.com/rust-lang/rust/pull/41029が完了したように見え

そのPRは放棄されましたが、復活し、＃48465で引き続き取り組んでいます。 現在クレーターを待っています。

@petrochenkov @nrc

syntax::ext::expandを見ると、 proc_macro_attributeは現在、いくつかのコンテキストで処理されていないようです（網羅的ではありません）。

• ブロック上（ fold_block()はnoopです）
• ステートメント/式について（＃41475、＃43988）
• extern {}ブロック内（＃48747）

RFC 1566には、属性マクロを適用できる特定のASTノードの種類がリストされていないため、ほぼすべてに適用できるはずです。 しかし、それは少しばかげている可能性があるので、処理する必要があるが処理する必要がないもの、および属性は許可されるべきではないが現在は許可されている可能性がある場所を明確に確立する必要があります（＃43988）

@abonanderの意図は、procマクロ属性は、通常の属性があり、他の場所では使用できないことです。これは、上記のすべてをカバーしていると思います（ただし、一部は安定していません。procマクロを安定させる場合は、次のことに注意する必要があります。他の属性に対して安定している用途のみを安定させます）。

@nrcは、これらの場所を列挙する場所にあります。これアイテムに適用できるとだけ記載されているためです。 ただし、lint属性はブロックやステートメントにも適用できるとほぼ確信しています。

@nrcは、これらの場所を列挙する場所にあります。これは、参照では、属性は任意のアイテムに適用できるとだけ記載されているためです。 ただし、lint属性はブロックやステートメントにも適用できるとほぼ確信しています。

afaikはありません-受け入れられたRFCと、任意の式の属性に対する不安定な機能フラグがありますが、ステートメントとブロックでのみ安定していると思います。 参照がデータ不足です。

この問題：

安定性チェック（proc-）マクロ（問題＃34079）。

現在、WRTproc-macrosは閉じられています。 私のPRは、Macros 2.0マクロの安定性チェックを追加しなかったため、問題はまだ解決されていません（ただし、おそらく新しい問題であるはずです）。

@rfcbotfcpマージ

Rust1.28リリースのマクロ1.2として安定化されたマクロ2.0ストーリーのサブセットを提案したいと思います。 Rust 1.28は2018年5月10日（この記事の執筆から約2.5週間）に毎晩入り、2018年8月2日に安定します。FCPは1.27のベータ版に入る5月10日のカットオフの前に終了する可能性があると思いますが、保持したいと思いますそのカットオフが発生するまでここで安定化をオフにし、これを1.28リリースまで遅らせます。

これは、 @ petrochenkovによって登録された多くの問題とともに最近内部で

ただし、これはサブセットであることを忘れないでください。 ここで機能が欠落しているからといって、コンパイラから安定化または削除されることはありません。 むしろ、この機能は、この提案された安定化パスの後も不安定なままであり、後日安定化されます。

use some_proc_macro_crate::bar;

#[bar]
fn baz() {}

use some_proc_macro_crate::bar;
bar!();

pub use some_proc_macro_crate::bar; // reexport an attribute or macro

extern crate proc_macro;
use proc_macro::TokenStream;

/// Invoked as `foo!()`
///
/// When invoked as `foo!(a b ( c ))` then the `TokenStream`
/// here will be `a b ( c )`.
///
/// The invocation is replaced with the `TokenStream` returned
#[proc_macro]
pub fn foo(a: TokenStream) -> TokenStream {
    // ...
}

/// Invoked as `#[bar]`
///
/// The first argument, `attr`, is the token stream inside of the attribute
/// itself. The second argument, `item`, is the token stream corresponding to
/// the item the attribute is attached to.
///
/// An attribute of the form `#[bar ( a b [ c ] )]` will have the `attr`
/// argument look like `a b [ c ]`. Note the lack of delimiters passed to
/// `attr`! An API may later be added to learn what delimiter a macro was
/// invoked with.
///
/// The `item` here is a tokenified version of the original item.
///
/// The return value here will contain all non-expanded attributes as well for
/// this attribute to inspect. The return value replaces the original item.
#[proc_macro]
pub fn bar(attr: TokenStream, item: TokenStream) -> TokenStream {
    // ...
}

pub struct TokenStream(_);

impl TokenStream {
    pub fn empty() -> TokenStream;
    pub fn is_empty(&self) -> bool;
}

impl Clone for TokenStream { ... }
impl Debug for TokenStream { ... }
impl Display for TokenStream { ... }
impl FromStr for TokenStream { ... }
impl From<TokenTree> for TokenStream { ... }
impl FromIterator<TokenTree> for TokenStream { ... }
impl FromIterator<TokenStream> for TokenStream { ... }
impl !Send for TokenStream { ... }
impl !Sync for TokenStream { ... }

impl IntoIterator for TokenStream {
    type Item = TokenTree;
    type Iter = token_stream::IntoIter;
}

pub mod token_stream {
    pub struct IntoIter(_);

    impl Iterator for IntoIter {
        type Item = ::TokenTree;
    }
}

pub enum TokenTree {
    Op(Op),
    Term(Term),
    Literal(Literal),
    Group(Group),
}

impl TokenTree {
    pub fn span(&self) -> Span;
    pub fn set_span(&mut self, span: Span);
}

impl Clone for TokenTree { ... }
impl Debug for TokenTree { ... }
impl Display for TokenTree { ... }
impl From<Op> for TokenTree { ... }
impl From<Term> for TokenTree { ... }
impl From<Literal> for TokenTree { ... }
impl From<Group> for TokenTree { ... }
impl !Send for TokenTree { ... }
impl !Sync for TokenTree { ... }

pub struct Span(_);

impl Span {
    pub fn call_site() -> Span;
}

impl Clone for Span { ... }
impl Copy for Span { ... }
impl Debug for Span { ... }
impl !Send for Span { ... }
impl !Sync for Span { ... }

pub struct Group(_);

pub enum Delimiter {
    Parenthesis,
    Brace,
    Bracket,
    None,
}

impl Group {
    pub fn new(delimiter: Delimiter, stream: TokenStream) -> Group;
    pub fn stream(&self) -> TokenStream;
    pub fn delimiter(&self) -> Delimiter;
    pub fn span(&self) -> Span;
    pub fn set_span(&mut self, span: Span);
}

impl Clone for Group { ... }
impl Debug for Group { ... }
impl Display for Group { ... }
impl !Send for Group { ... }
impl !Sync for Group { ... }

impl Copy for Delimiter { ... }
impl Clone for Delimiter { ... }
impl Debug for Delimiter { ... }
impl PartialEq for Delimiter { ... }
impl Eq for Delimeter { ... }

pub struct Term(_);

impl Term {
    pub fn new(s: &str, span: Span) -> Term;
    pub fn span(&self) -> Span;
    pub fn set_span(&mut self, span: Span);
}

impl Copy for Term { ... }
impl Clone for Term { ... }
impl Debug for Term { ... }
impl Display for Term { ... }
impl !Send for Term { ... }
impl !Sync for Term { ... }

pub struct Op(_);

pub enum Spacing {
   Alone,
   Joint,
}

impl Op {
    pub fn new(op: char, spacing: Spacing) -> Op;
    pub fn op(&self) -> char;
    pub fn spacing(&self) -> Spacing;
    pub fn span(&self) -> Span;
    pub fn set_span(&mut self, span: Span);
}

impl Debug for Op { ... }
impl Display for Op { ... }
impl Clone for Op { ... }
impl Copy for Op { ... }
impl !Send for Op { ... }
impl !Sync for Op { ... }

impl Copy for Spacing { ... }
impl Clone for Spacing { ... }
impl Debug for Spacing { ... }
impl PartialEq for Spacing { ... }
impl Eq for Spacing { ... }

pub struct Literal(_);

impl Literal {
  // panic on infinity and NaN
  pub fn f{32,64}_{un,}suffixed(f: f{32,64}) -> Literal;

  pub fn i{8,16,32,64,128,size}_{un,}suffixed(n: i{8,16,32,64,128,size}) -> Literal;
  pub fn u{8,16,32,64,128,size}_{un,}suffixed(n: u{8,16,32,64,128,size}) -> Literal;

  pub fn string(s: &str) -> Literal;
  pub fn character(c: char) -> Literal;
  pub fn byte_string(b: &[u8]) -> Literal;

  pub fn span(&self) -> Span;
  pub fn set_span(&mut self, span: Span) -> Span;
}

impl Clone for Literal { ... }
impl Debug for Literal { ... }
impl Display for Literal { ... }
impl !Send for Literal { ... }
impl !Sync for Literal { ... }

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

• [x] @Kimundi
• [] @SimonSapin
• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [x] @nrc
• [] @pnkfelix
• [x] @scottmcm
• [x] @sfackler
• [x] @withoutboats

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

レビューアの過半数が承認すると（そして反対はありません）、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

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

cc @ rust-lang / compiler、y'all私も知っていることですが、これにも非常に興味があります。異議を唱えてください。 ブロッキングの異議がある場合は、登録することもできます

安定化のために提案された提供されたAPIを使用すると、procマクロはあらゆる種類のトークンを簡単に生成したり、入力から出力にコピーしたりできますが、表面的なレベルでさえトークンのストリームを簡単に検査できないようです。 たとえば、 LiteralはEqまたはPartialEq実装していません。 その特別な理由はありますか？ （それでも、値を抽出してコードで処理するのではなく、指定された定数値との比較しかできません。）

TokenStream与えられた場合、procマクロの実装内で、procマクロはリテラルをイントロスペクトするために何ができますか？ または、そのことについては、1つの値を抽出しますか？ これは単にまだサポートされていませんか？ 今後もサポートする予定はありますか？

（私は提案されたサブセットの安定化をブロックしようとはしていません。そのサブセットとその意図された機能をよりよく理解したいと思います。）

@alexcrichton新しいアイテムは
衛生的ではありません。 ASTに追加された新しいアイテムは、と同じ名前空間に入ります
モジュール内の他のアイテム。

私はRustコアチームに所属しておらず、過去のすべての議論を十分に検討していませんが、これは私にとって本当に悪いことのように思えます。 マクロが、マクロからのみアクセスできるヘルパーアイテムを生成したい場合はどうなりますか？

衛生状態を捨てるよりも、完全な100％の衛生状態を強制する方が良いと思いますが、マクロが特定の変数の衛生状態を明示的にオプトアウトする方法を提供します。

@joshtriplettは、リテラルの

@joshtriplettええ、 @ dtolnayが言ったように、 Displayを使用します。これは、 literalextのような

この一連の安定化は、すべてのユースケースをカバーするために最小限の機能を提供するという意味で「最大限に最小限に抑える」ことを目的としています（ Literal場合はDisplayであり、それを解釈するものは他にありません）。 ）。

@Pauanそれは素晴らしいことではありませんが、それはmacro_rules!とまったく同じです。これは、何年もの間安定していて、さまざまなコンテキストで機能しています。 ここで衛生とより良い治療を可能にしたいとSpan::call_site()コンストラクターは、ここでの要であり、それを使用することで「衛生状態なし」を要求します。 最終的には、より多くのオプションを安定させます。

残念ながら、「完全な100％衛生」は数年先にあり、この提案の目的は、Rust2018で安定したものを入手することです。

@alexcrichtonでは、今は衛生ホールで安定させ、その後、いくつかのエポック/時代/エディションでその衛生ホールを修正する計画ですか？

Span::call_site()が存在するので、現在完全な衛生状態を保つことができない理由はありますか？ それは人的資源/時間の不足ですか、それともRFCで具体化する必要がある理論的/意味論的懸念がありますか？

@Pauanは、今日すでに存在しているという意味で、本当の「穴」は存在しないことを繰り返し述べます。 これは、 macro_rules!とカスタム派生のまったく同じ衛生ストーリーです。 この提案は事実上その延長であり、新しいものを導入するものではありません。

「完璧な衛生ストーリー」を考えると、私たちは常に何らかの形のオプトアウトを望んでいます。 現在、そのオプトアウトはSpan::call_site() （事実上）。 安定させるだけで、衛生のオプトアウトメカニズムを安定させるだけです。 最終的には、必要に応じてアイテムを完全に衛生的にするために、より多くの機能を安定させます。

衛生状態の安定化ははるかに遠いです。 （AFAIK）未解決の研究の質問があります、それは人的資源の問題ではありません。

@dtolnayああ、なるほど。 では、テキストを生成してから、テキストを再解析しますか？ とりあえずはうまくいくと思います。

cc @ rust-lang / compiler、y'all私も知っていることですが、これにも非常に興味があります。異議を唱えてください。 ブロッキングの異議がある場合は、登録することもできます

私はまだレビューすることがいくつかあり、いくつかのproc-macroAPIの調整が進行中のPRがあります。

これは、macro_rulesとまったく同じ衛生ストーリーです。 とカスタム派生。

もちろんですが、目標の1つはより良いマクロシステムを作ることだと思ったので、既存の（壊れた、制限された）システムを指すことは私にはあまり説得力がありません。

「完璧な衛生ストーリー」を考えると、私たちは常に何らかの形のオプトアウトを望んでいます。

もちろんですが、私のポイントは、必要に応じてSpan::call_site()を使用して衛生状態を破ることができるため（したがって、 macro_rules!機能を取得できるため） 、デフォルトで衛生状態にすることでだけで立ち往生して

最終的には、必要に応じてアイテムを完全に衛生的にするために、より多くの機能を安定させます。

むしろ迷惑な（と混乱を招く）バンドエイドのようなそれは音：PROCマクロは、ほとんどの状況（ただし項目）で衛生的になりますが、あなたはその後、アイテムのためにオプトイン衛生への新機能を使用することができます。 私はその権利を理解していますか？

（AFAIK）未解決の研究の質問があります、それは人的資源の問題ではありません。

さて、それは十分に公平です。 私は便宜と実用主義への欲求を理解しています。 後のエポック/時代/エディションで最終的にデフォルトでしっかりした衛生状態になる計画である限り、一時的に悪い衛生状態になっても大丈夫です。 後で後悔するようなものを安定させたくないだけです。

ある意味で、それはすでにある「デフォルトで衛生的、」それはデフォルトはまだサポートされていないだけということです。 Span::call_siteはオプトアウトです。 :)

@Pauan @alexcrichtonが言ったことを詳しく

識別子を作成するには、衛生情報を含むSpanが必要です。 （ Term::new ）

将来的には、 Spanを構築するためのさまざまな方法を公開する可能性があります。これは、衛生に関するさまざまなオプションを反映しています。 ただし、現時点では、呼び出し元のスコープを取得するSpan::call_siteのみを公開します。

このようにして、後で衛生状態を追加する機能を開いたまま、衛生システム全体をすぐに安定させることを回避できます。 この問題を回避するのはかなり賢いトリックだと思います！

@rpjohnstつまり、procマクロから新しいアイテムを返す唯一の方法は、 Span::call_siteを使用することです。

もしそうなら、それは完璧に聞こえます：その場合、衛生は確かに将来、クリーンで下位互換性のある方法で追加することができます。

@lfairyああ、なるほど、 Span::call_siteを使用する必要が

そのため、これ以上異議はありません。

@alexcrichton

属性、macro_rules、および手続き型
マクロはすべてmaro名前空間にあります。

最後に#[feature(proc_macro)]で確認しましたが、ここで説明するように、 derive-error-chainクレートの安定したコードに後方互換性のない変更がありました。 引用されたステートメントから、マクロ1.2ではこのようになり続けるようです。 あれは正しいですか？

@Arnavionああ、それは悪いですね！ 後方互換性のない大きな変更を実際に行うことはできないため、それを機能させ続ける方法を見つける必要があります。 考えられる解決策の1つは、「これは属性ではありません」エラーを#[derive]拡張後まで延期することです。

＃48644と＃47786が完了したようです。 誰かがOPを更新できますか？

@alexcrichton Literalとその友人の内部データへのアクセスを許可することについて何か議論がありましたか？ 下位互換性の理由で列挙型ではなくなったようですが、 Literalこのようなものを最初に使用できない理由はありますか？

    impl Literal {
        pub fn as_str(&self) -> Option<&str> {}
        pub fn to_int(&self) -> Option<i64> {}
        pub fn to_uint(&self) -> Option<u64> {}
        pub fn to_float(&self) -> Option<f64> {}
    }

さまざまなリテラルサブタイプに対して、多数のTryFrom implを作成することもできます。

@abonanderええ、それは議論されましたが、結論は、安定化の最初のパスに必要にするのではなく、後でそれらを追加することでした。 これらは、 Display実装を使用してcrates.io上に構築でき、将来的に追加する余地があります。

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

@alexcrichton
procマクロAPIタイプの!Sendおよび!Sync implsは明示的に記述されていませんが、推測されます。
一部の構造体（例： Op ）の場合、推測されるimplはhttps://github.com/rust-lang/rust/issues/38356#issuecomment-383693017で指定されているものとは異なります。
implを明示的に追加することはおそらく理にかなっています。

はい、確かにそうです！ これに対処するためにhttps://github.com/rust-lang/rust/pull/50453を開きました

@alexcrichton Term::as_str厄介な問題があります：厳密なスコープにより、 &'a Term -> &'a strを実装してスコープ内のインターナーに借用できるという非公式の証拠をスケッチしようとしていました。 'aは、インターナー自体のスコープより大きくなることはありません（これは、関数が成功した場合、つまり、インターナーが存在するスコープ内で呼び出された場合にのみ重要です）。

AFAICT、 Term::as_strは健全ですが、 'a条件を想定しているだけです。

これは、たとえばthread_local!によって支持されます。これは、 Term値をエスケープできる一方で、非常に短命の'aを提供するためです。これは、 Term::as_str成功し、内部スコープよりも厳密に短くなります。
一般に、 proc_macro拡張が行われる方法、およびTermはスレッドローカルであるため、 Termをエスケープする方法はほとんどなく、 thread_local!を想定しました。事実上唯一のものでした。

しかし、 Box::leakも存在します！ まだ不安定ですが、今日、 Box::leak(Box::new(term)).as_str()は&'static str返します。 Box::leak （cc @RalfJung）によって壊された他の抽象化があるのだろうか

OTOH、これは複雑です。 TermはCopyため、文字列データを所有できないためです。
TermのCopyを削除すると、そこに怠惰なOption<Cell<Rc<String>>を保持できます。

@eddyb oh Term::as_strは削除される予定であり、ここでは安定化に含まれていなかったので、心配する必要はありません。 proc-macro2壊さないように固執しているだけですが、これが安定したら、 proc-macro2壊れた変更をリリースできます。

@eddybここでのコンテキストはわかりませんが、正式なモデルではBox::leakが正当化されます。 あなたが永遠に（すなわち、箱の中に）いくらかの記憶を所有しているなら、あなたはそれがどんな寿命も持っていると完全に言うことができます。

いくつかの質問を聞きたいんです：

1. quote!は安定していませんか？
2. quote!にはproc_macro_non_items機能ゲートが適用されますか？ Commit 79630d4fdfc775b241cae0a209edec2687a29f0fで必要になりましたが、 quote!は引き続き#[unstable(feature = "proc_macro" ...マークされています。
3. proc_macro_path_invoc 、 proc_macro_mod 、 proc_macro_expr 、およびproc_macro_non_itemsの安定化のために、追跡の問題が提出されますか？

_{無関係な副次的な質問： quote!はどこに実装されていますか？}

すっごく楽しい物語@mjbshaw：それがで実装されているproc_macro::quote 。
rustc_metadataは、 proc_macroという名前のクレートにquoteという名前の手続き型マクロが含まれているように見せかけますが、使用される実装はproc_macro rustc_metadataに対するリンク。

私はまだレビューすることがいくつかあり、いくつかのproc-macroAPIの調整が進行中のPRがあります。

PRのレビュー： https ：

1.2 APIの機能リクエスト：山かっこ（ < / > ）の区切り文字を追加して、 <T> （ fn foo<T>() {} ）のようなものが次のように解析されるようにします。 Group 。 これを行わないと、たとえばジェネリックの解析が不必要に複雑になります。

@mjbshaw 2つの< >が互いにグループ化されているかどうかを判断しようとすることは、トークンレベルでは機能しないと思います。 たとえば、次のマクロ入力では、次のようになります。

m!($A<$B, $C>=$D);

これは、2つのブール式$A < $Bと$C >= $Dであるか、たとえばtype $A <$B,$C> = $D;展開されるような型エイリアスのジェネリックスを表している可能性があります。

assert_both!(a<AMAX, b>=BMIN);

define_type_alias!(SwappedResult<E, T>=std::result::Result<T, E>);

OPを少し更新しましたが、結果に応じて、衛生に関連する2つの可能性のあるショートッパーバグのように見えます。

• 衛生状態がおかしい
• 衛生はもっと奇妙です

このスレッドをフォローしている場合、APIは@petrochenkovによって提案されたhttps://github.com/rust-lang/rust/pull/50473の元のFCPコメントから変更される可能性があります。 これまでの要約は次のとおりです。

• Term::new名前をTerm::identに変更し、入力を検証します
• Term::lifetimeを追加し、入力を検証します
• Term::raw_identを追加し、入力を検証します
• Op名前をPunct
• Punct::new入力を検証します
• Op::op名前をPunct::as_char

私が行うマイナーなAPIリクエストの1つ（おそらく＃50473- @ petrochenkov）は、TokenStreamにトークンを追加する方法です。 おそらく：

impl Extend<TokenTree> for TokenStream

これにより、 quote::Tokensタイプ（基本的にはVec<TokenTree> ）を排除し、すべて「いくつかのトークン」を意味するエコシステム内のさまざまなタイプの拡散を減らすことができると思います-httpsで追跡

@dtolnayの上記の提案に+1。

上記のマージする傾向のある最後のコメント期間が完了しました。

2つの質問があります：

1. すでにここで尋ねられたようquote!どうですか？ 最終的なTokenStreamを作成するためのデフォルトの方法は何ですか？ 手動で行う必要がありますか？ または、 quoteクレートを使用する必要がありますか？ proc_macro::quote!は将来のある時点で安定するはずですか？

2. 関数のようなマクロと属性のようなマクロの宣言の違いは引数の数だけであるという点で、私の理解は正しいですか？ NS：

   /// Invoked as `foo!()`
   #[proc_macro]
   pub fn foo(a: TokenStream) -> TokenStream {
       // ...
   }
   
   /// Invoked as `#[bar]`
   #[proc_macro]
   pub fn bar(attr: TokenStream, item: TokenStream) -> TokenStream {
       // ...
   }
   

   唯一の違いは、一方が引数として1つのTokenStreamを取り、もう一方が2つを取ることです。 これは少し微妙ではありませんか？ 代わりに#[proc_macro_attribute]と#[proc_macro_function_like]使用してみませんか？ これはどこかで議論されましたか？ もしそうなら、誰かが議論をリンクすることができれば私は幸せです。

これに取り組んでくれてありがとう！ :)

@LukasKalbertodt属性は現在、 #[proc_macro_attribute]宣言されています。 それを変更する意図があるのか​​、それともFCP提案のタイプミスなのかはわかりません。

問題：文字列から解析されたトークンはSpan::call_siteスパンを取得しません： https ：//github.com/rust-lang/rust/issues/50050#issuecomment-390520317。

これを変更し、 Span::call_siteが返すものを変更して、呼び出しサイトスパンを使用するトークンのマクロバックトレース、クリップ、およびエディションの衛生状態を修正する必要があると思います。

@LukasKalbertodt proc_macroクレートのquote!マクロは、このFCPの一部として安定化されていませんが、crates.ioのquoteクレートは、ここで提案されているAPIに基づいています。 また、 @ abonanderが指摘したように、属性マクロは#[proc_macro_attribute]宣言され、 #[proc_macro]はfoo!()スタイルのマクロ専用に予約されています

#[proc_macro_attribute]に#[proc_attribute_macro]または#[attribute_proc_macro]という名前を付けるべきではありませんか？

@Zoxcすでに#[proc_macro_derive]安定しているので、属性マクロでこれに従わないのは不思議です。

我々は得ることができますPartialEq<char>とPartialEq<Punct>についてPunct （に似IdentのPartialEqの実装を）？ 追加するのはかなり安全なようです。 私はPRを書いてうれしいですが、アイデアが失敗した場合は書きたくありません。

@mjbshaw PartialEq<Punct>もスパンを比較しますか？ PartialEq<char>は問題ないようです、OTOH。

@eddyb PartialEq for Identはスパンを比較しません（これはproc-macro2ソースであり、proc-macroソースでPunctとIdentはこの点で同様に動作すると予想されます。 Punctも独自のSpacing 、これは比較に含まれると思います（ただし、他の人の考え方は異なるかもしれません）。

今のところ、 Punctに対してPartialEq<char>を実装するだけで問題ありません。 PartialEq<Punct>は後でハッシュ化できます。

@mjbshaw proc-macro2クレートには、 proc_macroが上流にあるものとproc_macroに追加できると思いますが、もちろん、 proc_macroに追加することは下位互換性があるため、最低限の方法から始めます。安定したら、そこからスケールアップできます。

マクロ1.2に関連するすべてのバグに対してトリアージ作業を行いました。 ほとんどのバグは、「重大なバグ」または「すべてのスパンに関連するバグ」に分類できます。 現在、スパン関連のバグは純粋にエラーメッセージに影響します（マクロ1.2の目的は解像度を変更することではないため）。 残りのスパンに関連しないバグ（別名深刻）はhttps://github.com/rust-lang/rust/issues/50050で、 @ petrochenkovには解決策があります。

Gnomeクラスは、proc_macro2 / syn / quoteの変更に加えて、procマクロからモジュールを生成するための機能ゲートで機能しなくなりました。 幸いなことに、現在は修正されています。

この小さなエコシステムの変化を把握するには、何を監視する必要がありますか？

@federicomenaquintero不安定な機能を使用する場合は、最新のNightlyでコードをコンパイルし、失敗した場合に通知する定期的なCIジョブ（毎日、毎週、

@SimonSapinありがとう、それはいい考えです。 これらのクレートのバージョンをCargo.tomlに固定しますが、バージョン番号を削除して、Cargoに最新のものをダウンロードさせる時期かもしれません。 これは正しい方法ですか？

@federicomenaquinteroこれはますます話題から外れているので、この議論を続けたい場合は、IRCやhttp://users.rust-lang.org/などの他の場所で行ってください。ただし、一般的な推奨事項は、アプリケーション（ライブラリとは対照的に）は、依存関係を効果的に固定するソースコードと一緒にCargo.lockを出荷する必要があります。 Cargo.tomlでは、 foo = "1.2.3"ような依存関係を宣言することをお勧めします。これは、「SemVerに従って互換性がある場合は、そのバージョン以降」を暗黙的に意味します。

そのため、作成したいクレートの開発を妨げている手続き型マクロの問題に遭遇しました。

次のことを考慮してください。

#[my_attribute]
struct MyStruct {
  #[other_attribute]
  field: String,
}

proc_macroとcustom_attributes両方の機能が必要ですが、同時に使用することはできないため、これは現在機能しません。 procマクロの安定化により、機能フラグが不要になることを理解していますか？

もう1つは、この方法で#[my_attribute]が、 #[other_attribute]実行を妨げるコードを生成する可能性があることです。 「outer」属性で、 #[derive(Foo)]と同じように機能する内部属性を登録できたら、本当にすばらしいでしょう。

ダミーセッションに関する

このパニックを暗黙的にダミーの「セッション」を作成することで置き換えることは可能/望ましいでしょうか？ または、パブリックAPI（安定化へのパスを含む）を追加して作成しますか？

ダミーセッションがあるととても便利だと思います。 proc-macroクレートの単体テストを作成することはほとんど不可能であるか、少なくともそれ以外の場合は非常に不便です。 さらに、それはTokenStream::from_strでなく、セッションを必要とする他の関数でもあります。

@alexcrichton

マクロ1.2に関連するすべてのバグに対してトリアージ作業を行いました。 ほとんどのバグは、「重大なバグ」または「すべてのスパンに関連するバグ」に分類できます。

https://github.com/rust-lang/rust/issues/50504を「重大」ステータスにアップグレードしたい-モジュールの問題は、より深い問題の症状のみであると説明されています-procマクロの拡張IDは正しく登録されている。 これが他にどのような結果をもたらすかはわかりません。
根本的な問題を修正するPRがあります（https://github.com/rust-lang/rust/pull/51952）が、修正からのリグレッションがあり、私はまだそれらを調べていません。

より多くの手続き型マクロを安定させるためのPRをhttps://github.com/rust-lang/rust/pull/52081に投稿しました

@petrochenkovは私にはいいですね、PRについてコメントします

proc_macro_derive子属性の問題と、それらがネーミングシステムとどのように相互作用するかについて、マクロネーミングトラッキングの問題について投稿しproc_macro_derive子属性がスコープと名前付けと相互作用する方法には別の問題がありますが、ここで取り上げる方が適切なようです。 属性のパスは現在安定化の過程にないため、 #[derive(foo::Parent)]が子属性#[foo::Child]持つ可能性がありますが、派生マクロは、その表面上、名前検索を実行できないため、子属性が実際にそれ自体の子であるかどうかを識別します。 今のところ、簡単な解決策はありませんが、相互に依存する属性の将来のために注目すべきものだと思います。 proc_macro_attribute属性が、同様のルックアップの問題に遭遇するような方法で相互作用することを望まなかった理由はありません。

今日、プロジェクトをコンパイルしようとしましたが、おそらくこの問題に関連する何かが壊れています。 すべてのエラーメッセージには、「（問題＃38356を参照）」というメッセージが含まれていました。 これが私がここにたどり着いた方法です。
ここに、コンパイル中に表示されたエラーメッセージを含めます。 Cargo.tomlも含めます。

私のプロジェクトは特定のRustナイトリーバージョン（rustc 1.29.0-nightly（9bd8458c9 2018-07-09））に固定されているため、これは非常に驚くべきことです。何が変わったのでしょうか。 おそらくライブラリが更新されましたか？

[[bin]]
name = "main"
path = "src/bin/main.rs"

[dependencies]
log = "0.4"
pretty_env_logger = "0.2"

rand = "0.4"
ring = "=0.13.0-alpha"
untrusted = "0.6"

bytes = "0.4"
futures = "0.1"
tokio-io = "0.1"
tokio-core = "0.1"
futures-await = "0.1"

capnp = "0.8"
rusqlite = "0.13"

async_mutex = { git = "https://github.com/realcr/async_mutex", rev = "a1d973ed7" }

num-bigint = "0.2.0"
num-traits = "0.2.4"

[dev-dependencies]

[dependencies.byteorder]
version = "1.1"
features = ["i128"]

[build-dependencies]
capnpc = "0.8"

[profile.release]
debug = true

$ cargo test
    Updating git repository `https://github.com/realcr/async_mutex`
   Compiling proc-macro2 v0.4.8                                                                                                                                                                                    
   Compiling cswitch v0.1.0 (file:///home/real/projects/d/cswitch)                                                                                                                                                 
error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)8: proc-macro2                                                                                                                        
  --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:33:40
   |
33 |     let works = panic::catch_unwind(|| proc_macro::Span::call_site()).is_ok();
   |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:213:13
    |
213 |     Nightly(proc_macro::token_stream::IntoIter),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:438:11
    |
438 | impl From<proc_macro::Span> for ::Span {
    |           ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:284:13
    |
284 |     Nightly(proc_macro::SourceFile, FileName),
    |             ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:332:13
    |
332 |     Nightly(proc_macro::Span),
    |             ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:461:13
    |
461 |     Nightly(proc_macro::Ident),
    |             ^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:523:13
    |
523 |     Nightly(proc_macro::Literal),
    |             ^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:116:47
    |
116 |                     Delimiter::Parenthesis => proc_macro::Delimiter::Parenthesis,
    |                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:117:43
    |
117 |                     Delimiter::Bracket => proc_macro::Delimiter::Bracket,
    |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:118:41
    |
118 |                     Delimiter::Brace => proc_macro::Delimiter::Brace,
    |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:119:40
    |
119 |                     Delimiter::None => proc_macro::Delimiter::None,
    |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:122:33
    |
122 |                 let mut group = proc_macro::Group::new(delim, tt.stream.inner.unwrap_nightly());
    |                                 ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:128:39
    |
128 |                     Spacing::Joint => proc_macro::Spacing::Joint,
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:129:39
    |
129 |                     Spacing::Alone => proc_macro::Spacing::Alone,
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:131:30
    |
131 |                 let mut op = proc_macro::Punct::new(tt.as_char(), spacing);
    |                              ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:113:17
    |
113 |         let tt: proc_macro::TokenTree = match token {
    |                 ^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:238:13
    |
238 |             proc_macro::TokenTree::Group(tt) => {
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:240:21
    |
240 |                     proc_macro::Delimiter::Parenthesis => Delimiter::Parenthesis,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:241:21
    |
241 |                     proc_macro::Delimiter::Bracket => Delimiter::Bracket,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:242:21
    |
242 |                     proc_macro::Delimiter::Brace => Delimiter::Brace,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:243:21
    |
243 |                     proc_macro::Delimiter::None => Delimiter::None,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:250:13
    |
250 |             proc_macro::TokenTree::Punct(tt) => {
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:252:21
    |
252 |                     proc_macro::Spacing::Joint => Spacing::Joint,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:253:21
    |
253 |                     proc_macro::Spacing::Alone => Spacing::Alone,
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:259:13
    |
259 |             proc_macro::TokenTree::Ident(s) => ::Ident::_new(Ident::Nightly(s)).into(),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:260:13
    |
260 |             proc_macro::TokenTree::Literal(l) => ::Literal::_new(Literal::Nightly(l)).into(),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:289:20
    |
289 |     fn nightly(sf: proc_macro::SourceFile) -> Self {
    |                    ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:339:27
    |
339 |             Span::Nightly(proc_macro::Span::call_site())
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:347:27
    |
347 |             Span::Nightly(proc_macro::Span::def_site())
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:369:30
    |
369 |     pub fn unstable(self) -> proc_macro::Span {
    |                              ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:430:32
    |
430 |     fn unwrap_nightly(self) -> proc_macro::Span {
    |                                ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:439:24
    |
439 |     fn from(proc_span: proc_macro::Span) -> ::Span {
    |                        ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:468:48
    |
468 |             Span::Nightly(s) => Ident::Nightly(proc_macro::Ident::new(string, s)),
    |                                                ^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:475:48
    |
475 |             Span::Nightly(s) => Ident::Nightly(proc_macro::Ident::new_raw(string, s)),
    |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:495:32
    |
495 |     fn unwrap_nightly(self) -> proc_macro::Ident {
    |                                ^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:583:30
    |
583 |             Literal::Nightly(proc_macro::Literal::f32_unsuffixed(f))
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:591:30
    |
591 |             Literal::Nightly(proc_macro::Literal::f64_unsuffixed(f))
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:599:30
    |
599 |             Literal::Nightly(proc_macro::Literal::string(t))
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:607:30
    |
607 |             Literal::Nightly(proc_macro::Literal::character(t))
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:615:30
    |
615 |             Literal::Nightly(proc_macro::Literal::byte_string(bytes))
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:636:32
    |
636 |     fn unwrap_nightly(self) -> proc_macro::Literal {
    |                                ^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/lib.rs:322:30
    |
322 |     pub fn unstable(self) -> proc_macro::Span {
    |                              ^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:531:34
    |
531 |                   Literal::Nightly(proc_macro::Literal::$name(n))
    |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
...
552 | /     suffixed_numbers! {
553 | |         u8_suffixed => u8,
554 | |         u16_suffixed => u16,
555 | |         u32_suffixed => u32,
...   |
565 | |         f64_suffixed => f64,
566 | |     }
    | |_____- in this macro invocation
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:543:34
    |
543 |                   Literal::Nightly(proc_macro::Literal::$name(n))
    |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
...
568 | /     unsuffixed_integers! {
569 | |         u8_unsuffixed => u8,
570 | |         u16_unsuffixed => u16,
571 | |         u32_unsuffixed => u32,
...   |
578 | |         isize_unsuffixed => isize,
579 | |     }
    | |_____- in this macro invocation
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
  --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:45:34
   |
45 |             TokenStream::Nightly(proc_macro::TokenStream::new())
   |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
  --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:53:46
   |
53 |             TokenStream::Nightly(tts) => tts.is_empty(),
   |                                              ^^^^^^^^
   |
   = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:123:23
    |
123 |                 group.set_span(span.inner.unwrap_nightly());
    |                       ^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:132:20
    |
132 |                 op.set_span(tt.span().inner.unwrap_nightly());
    |                    ^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:239:38
    |
239 |                 let delim = match tt.delimiter() {
    |                                      ^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:245:74
    |
245 |                 let stream = ::TokenStream::_new(TokenStream::Nightly(tt.stream()));
    |                                                                          ^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:247:58
    |
247 |                 g.set_span(::Span::_new(Span::Nightly(tt.span())));
    |                                                          ^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:251:40
    |
251 |                 let spacing = match tt.spacing() {
    |                                        ^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:255:43
    |
255 |                 let mut o = Punct::new(tt.as_char(), spacing);
    |                                           ^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:256:58
    |
256 |                 o.set_span(::Span::_new(Span::Nightly(tt.span())));
    |                                                          ^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:290:45
    |
290 |         let filename = stable::file_name(sf.path().to_string());
    |                                             ^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:304:44
    |
304 |             SourceFile::Nightly(a, _) => a.is_real(),
    |                                            ^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:355:69
    |
355 |             (Span::Nightly(a), Span::Nightly(b)) => Span::Nightly(a.resolved_at(b)),
    |                                                                     ^^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:363:69
    |
363 |             (Span::Nightly(a), Span::Nightly(b)) => Span::Nightly(a.located_at(b)),
    |                                                                     ^^^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:424:55
    |
424 |             (Span::Nightly(a), Span::Nightly(b)) => a.eq(b),
    |                                                       ^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:482:50
    |
482 |             Ident::Nightly(t) => Span::Nightly(t.span()),
    |                                                  ^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:489:56
    |
489 |             (Ident::Nightly(t), Span::Nightly(s)) => t.set_span(s),
    |                                                        ^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:623:56
    |
623 |             Literal::Nightly(lit) => Span::Nightly(lit.span()),
    |                                                        ^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error[E0658]: use of unstable library feature 'proc_macro' (see issue #38356)
   --> /home/real/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-0.4.8/src/unstable.rs:630:62
    |
630 |             (Literal::Nightly(lit), Span::Nightly(s)) => lit.set_span(s),
    |                                                              ^^^^^^^^
    |
    = help: add #![feature(proc_macro)] to the crate attributes to enable

error: aborting due to 63 previous errors

For more information about this error, try `rustc --explain E0658`.
error: Could not compile `proc-macro2`. 

何がうまくいかなかったのか、どうすれば修正できるのか考えていますか？ ありがとう！

用@realcr proc-macro2クレートあなたは、単に実行することができますcargo update 、それはトリックを行う必要があります！

@alexcrichtonここでは問題はないと思います。 エラーメッセージにはどこでもproc-macro2-0.4.8と表示されているので、 @ realcrはすでにproc-macro2更新していると思います。 問題は、ナイトリーバージョンが＃52081を含まないバージョンに修正されていることです。 私は今日同じ問題を抱えていて、なぜproc-macro2がマイナーバージョンにしかぶつからないのか疑問に思いました。 しかし、私はproc-macro2が互換性を処理する方法にあまり精通していません。

@realcr毎晩コンパイラを更新するか、プロジェクトにproc-macro-2バージョン< 0.4.8してみてください。

@ alexcrichton 、 @ LukasKalbertodt ：迅速な返信ありがとうございます。
毎晩のコンパイラを最新バージョンに更新しました。 proc-macro-2の問題は解消されましたが、多くの新しいコンパイルエラーが発生しました。 例：

error[E0277]: the trait bound `impl futures::Future: std::future::Future` is not satisfied
   --> src/networker/messenger/handler/handle_neighbor.rs:191:25
    |
191 |         let signature = await!(self.security_module_client.request_signature(failure_signature_buffer))
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `impl futures::Future`
    |
    = note: required by `std::future::poll_in_task_cx`
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

...

error[E0627]: yield statement outside of generator literal
   --> src/networker/messenger/handler/handle_neighbor.rs:403:13
    |
403 | /             await!(self.reply_with_failure(remote_public_key.clone(), 
404 | |                                            channel_index,
405 | |                                            request_send_msg.clone()))?
    | |_____________________________________________________________________^
    |
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

確認するために、私の現在のバージョンのrustc：

rustc 1.29.0-nightly (1ecf6929d 2018-07-16)

問題の原因を追跡するために、 futures_awaitから基本的な例をコンパイルしようとし機能しなくなりました。 この問題を解決できるように、そこで問題を提出します。

@LukasKalbertodt https://github.com/alexcrichton/proc-macro2#unstable -features

不安定な機能を使用しているためです。

@realcr新しいコンパイルの問題は、この問題とは関係ありません。トピックにとどまってください。

@TeXitoi ：関係がないと思われる場合は、自由に編集または削除してください。 私はあなたを助けるために最善を尽くします、私が話題になっているものとそうでないものを知ることは難しいです。 エラーメッセージ「（issue＃38356を参照）」が私をここに連れてきたものです。

コンパイラのバージョンをアップグレードしようとしましたが、このエラーが発生しました。 私のコード

#![no_std]
#![feature(proc_macro)]
#![feature(proc_macro_gen)]
#![feature(custom_attribute)]
#![feature(alloc)]

#[macro_use(eth_abi)]
extern crate pwasm_abi_derive;

#![feature(proc_macro)]使用しなかったというエラーが表示されましたが、使用しました。

error[E0658]: attribute procedural macros are experimental (see issue #38356)
  --> src\lib.rs:67:5
   |
8  | #[macro_use(eth_abi)]
   |             ------- procedural macro imported here
...
67 |     #[eth_abi(TokenEndpoint, TokenClient)]
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(proc_macro)] to the crate attributes to enable

@Pzixel #![feature(proc_macro)]を#![feature(use_extern_macros)]に切り替えたいと思うでしょう、そしてそれはトリックをするはずです

手続き型マクロをインポートするには、モジュールシステムも使用する必要があると思います（そして、最新の夜間コンパイラーがあることを確認してください）。

@alexcrichtonはい、記事のおかげで私はそれを理解しました。 ただし、それでも機能しません。

error[E0433]: failed to resolve. Use of undeclared type or module `Vec`
  --> src\lib.rs:66:5
   |
66 |     #[eth_abi(TokenEndpoint, TokenClient)]
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Use of undeclared type or module `Vec`

error[E0412]: cannot find type `Vec` in this scope
  --> src\lib.rs:66:5
   |
66 |     #[eth_abi(TokenEndpoint, TokenClient)]
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope

マクロのインポートルールも変更されましたか？ または、なぜここで文句を言い始めたのか理解できません。

手続き型マクロまたはコンパイラのバグである可能性のある@Pzixel 、そのための専用の問題を提出できますか？

まあ、私は最初にコードを書き直して、少なくとも機能しているように見えるようにする必要があると思います:)今はそうではありません、皆さんはこの機能で大きく変更しました。 完了したらBRB。 それが消えない場合は、問題を作成します。

@alexcrichton
トークンが手続き型マクロに渡される前に、トークンにどのような「前処理」が適用されるか知っていますか？
派生は、入力トークンを取得する前に、少なくとも$crate削除され、 cfg拡張されていることを知っています（さらに、文字列のラウンドトリップは完全にロスレスではありませんが、修正可能です）。

新しく安定化された手続き型マクロでこれが発生しないこと、および入力トークンを正確に取得すること（モジュロバグ）を確認する必要があります。

@alexcrichton申し訳ありませんが、 cargo expandは、何らかの理由でこのクレートでは機能しません。 問題が私の側にあるのか、コンパイラの側にあるのかを確認できません。 ですから、この可能性が完全に排除されなくなるまで、私は自分を責め続けます。

@petrochenkov proc-macrosの拡張はこれまでかなりよく吟味されてきたので、名前解決の部分よりもはるかに心配していません。 私は個人的に前処理を認識していませんが、派生が最後に実行され、cfgが最初に実行される拡張順序があることを知っています。それ以外の場合は、ほとんどが反復的です。

監査するのは良いことですが、私は同意します！

多分私は明白な何かを逃しました。 しかし、proc_macroから関数を呼び出したり、型を使用したりする方法はありません-手続き型マクロ展開からクレートを定義しますか？ （またはproc_macroクレート、FWIWから知られている他のクレート）

回避策はありますが、手続き型マクロのユーザーがクレートの名前を変更すると、AFAIUは機能しません。

@Ekleog proc-マクロクレートは通常、それらを使用するクレートを構築する目的でのみコンパイルされます。 これらは実行時の依存関係ではありません。 proc-macro crate全体は、「通常の」ライブラリではなく、一種のコンパイラプラグインと考えることができます。

これは、クロスコンパイル時に特に顕著です。ビルドスクリプトのように、proc-macrosは、ターゲットプラットフォームではなく、ホストプラットフォーム用にコンパイルされます。

@SimonSapin私はあなたに同意しますが、それがproc-macroクレートではない場合でも、クレートによって提供される関数に作業の一部を委任することは本当に役立つかもしれません（たとえば、上記の私のリンクでは、 X-derive crateは、 X crateの関数を使用しようとします）。 それ以外の場合は、proc-macrosによって生成されるすべてのコードが自己完結型であるか、呼び出しサイトの状態を想定する必要があることを意味します。

次に、rustcはまだこの種の機能の準備ができていないことを理解できます（長い間どこかにあるように見える非proc-macroクレートからproc-macroを分割する必要がなくても最もうまくいくと思うからです-用語ロードマップ）。 しかし、 TokenStreamsのみを使用している現在のインターフェースが安定している場合、この機能を後で後付けすることは可能でしょうか？ PathToBeResolvedFromTopOfGeneratingProcMacroCrateトークンタイプのようなものは必要ではないでしょうか？ （これは、後で追加された場合、重大な変更になります、afaiu）

最終的には物事をより柔軟にすることが可能になるかもしれませんが、それはかなり遠いようです。

それまでの間、ライブラリの作成者である場合は、手続き型マクロ用にfoo-proc-macrosまたはfoo-deriveクレートと、ランタイムを含む「通常の」 fooライブラリを用意することを検討してください。コードだけでなく、手続き型マクロを再エクスポートします。 このようにして、ユーザー向けのAPIを単一のクレートに保持できます。 これはserdeが行うことです（一部の構成では） https://github.com/serde-rs/serde/blob/v1.0.71/serde/src/lib.rs#L304

ただし、この回避策では、ユーザーがルートクレートの名前を変更する問題（たとえば、

#![feature(proc_macro)]は、1.29.0以降安定しているとマークされています。 これは意図されたものですか？

@ CAD97 、間違いなく。 https://github.com/rust-lang/rust/commit/65f3007fa8a08daf77f2b8382a56eb80cb277131およびhttps://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252を参照して

@Ekleog 、 TokenStreamはTokenTreeのストリームであり、各TokenTreeはスコープ情報を運ぶSpanが関連付けられています。 現在、「呼び出しサイト」（または空）以外のスコープのスパンを作成する方法がないことを除いて。 基本的に、特定のクレートを参照してSpanを作成するための合理的に人間工学的な方法を考え出すことが、必要なことです。

私が尋ねた理由は、チェックボックスがチェックされていないからです。 それならそれをチェックするのがいいでしょう！

#![feature(proc_macro)]安定した状態で、この問題の残りは何ですか？

@ jan-hudecああ、初期のブログ投稿でこの役割を果たしたHygiene （または同様の名前の）構造体について言及されていたため、 Spanはエラー報告専用だと思いました。 私はこれらが消えたと思っていました、そして明らかに間違っていました。 ありがとう！ :)

＃！[feature（proc_macro）]が安定した状態で、この問題の残りは何ですか？

理想的には、安定した機能ではなく、残っているすべての個々の問題について新しい問題を提出する必要があります。そうすれば、この問題を閉じることができます（https://github.com/rust-lang/rust/issues/で行われたのと同じ方法で） 44660）。

ああ、初期のブログ投稿でこの役割を果たした衛生（または同様の名前の）構造体について言及されていたため、スパンはエラー報告専用だと思いました。 私はこれらが消えたと思っていました、そして明らかに間違っていました。 ありがとう！ :)

IIUC、スパンは、衛生状況を追跡するための主要な方法です。

@ mark-im種類。 これらには、ソースコードの場所情報（ユーザー向けのメッセージ/診断用）と構文コンテキスト（つまり、衛生情報）の両方が含まれます。

この問題が発生するディスカッション/トラフィックの量を考えると、 proc_macro_diagnosticを独自の追跡問題に移動することは理にかなっていますか？ また、その機能を安定させるためのブロッカーが何であるかを理解し、それを押し通すことができるかどうかを確認したいと思います。 ディーゼルはそれを使用します、そしてそれはこれまで素晴らしいです。 安定版にこの機能がないため、コミュニティは、代わりにcompile_error!を使用するsynの最新バージョンのように、ファンキーな回避策を作成しています。

@sgrif私はそのような問題を開いた： https ：

だから私はSpanとLineColumn構造体のメソッドを安定させるのを手伝うことに興味があります。 最初のコメントで未解決の問題を見ていきますが、誰かが初心者に特定の方向でコンパイラーを紹介したい場合は、それをいただければ幸いです：+1：

proc_macro_gen機能ゲートはここで私を指していますが、上部のチェックリストには、他のマクロ定義を生成する（proc_）マクロを明らかに参照しているものは何もありません。 これは（rustcの機能ゲート以外で）説明されていますか？

@jjpe現時点では、これらの機能ゲート専用の追跡問題をスピンオフするのがおそらく最善です。この問題は、主に安定化の最初の波に捧げられました。

@alexcrichton私はそれで完全に元気です、それはproc_macro_gen機能を見る過程で、それはそれについての言及がないのと同じくらい良いものを見つけるためにここで私を紹介しただけです。 それは私には少し奇妙なので、少なくともそれについて言及することにしました。

@xieyuheng CodeString / Codeはどのように見えるでしょうか。つまり、そのセマンティクスはどうなるでしょうか。
TokenStreamは、面倒なテキストではなく一連のトークン値を除いて、そのままのソースコードにすぎないことに注意してください。

TokenStream （ TokenTree ）の拡張APIは1.29で安定しています。 関数のようなprocマクロのインポートは1.30で安定します。

rustc 1.30.0-nightly (63d51e89a 2018-09-28)以降、モジュール内のコードを別のファイルでトラバースすることはできなくなったようです。 mod module;を処理すると、 mod module; 、WYSIWYGを含むTokenStreamが得られます。

これは、スパン、衛生状態、および処理されたコードとの一貫性を維持するために必要であることを理解しています。 別のファイルのモジュールのコンテンツを操作する方法はありますか、またはありますか？ モジュール構成の些細なリファクタリングがマクロの動作に変化をもたらす場合、その欠如はエンドユーザーを混乱させる可能性があります。

わかりました。この問題は大規模であり、これ以上開いたままにしてAPIを追跡することはあまり役に立たないと思うところまで来ています。 そのために、 https：//github.com/rust-lang/rust/pull/54728を開きました

• https://github.com/rust-lang/rust/issues/54722-$＃$ quote!マクロ
• https://github.com/rust-lang/rust/issues/54723-$＃$ Ident::new_raw
• https://github.com/rust-lang/rust/issues/54724-$＃$ Span::def_site
• https://github.com/rust-lang/rust/issues/54140-$＃$ proc_macroと診断
• https://github.com/rust-lang/rust/issues/54725-$＃$ proc_macro::Span検査
• https://github.com/rust-lang/rust/issues/54726-カスタム内部属性を許可する
• https://github.com/rust-lang/rust/issues/54727-「hygiene2.0 」レポートの一種のキャッチオールであり、それ自体をシャーディングすることをお勧めします。

この時点でこれを終了しますが、他の追跡の問題を分割するのを忘れた場合は、お知らせください。 私は確かにいくつかのフォローアップを開くことができます

@alexcrichton属性のようなマクロのサブ属性はどうですか？
https://github.com/rust-lang/rust/issues/38356#issuecomment -397095541
これに問題はありますか？

@XX
このようなサブ属性は、必ずしも言語機能である必要はありませんか？
derive場合、派生マクロは入力から属性を削除できないため、カスタム属性の登録が必要です（入力は不変です）。
属性マクロは入力から#[other_attribute]を削除できるため、名前解決に到達したり、「未解決の属性」エラーを報告したりすることはありません。

（https://github.com/rust-lang/rust/issues/38356#issuecomment-397095541に記載されている従来のレガシーの不安定なカスタム属性に加えて、procマクロと互換性があります。）

@petrochenkovはい、説明してくれてありがとう。