सीसी @nrc @jseyfried

मैं चाहता हूं कि #[proc_macro_attribute] को जल्द ही लागू किया जाए। मेरे पास पहले से ही एक प्रोटोटाइप और परीक्षण उपयोग है जिसे मैंने महसूस करने से पहले धमाका किया है कि अभी तक कोई कंपाइलर समर्थन नहीं है: अप्रयुक्त::

प्रोटोटाइप: https://github.com/abonander/anterofit/blob/proc_macro/macros/src/lib.rs
उदाहरण/परीक्षण: https://github.com/abonander/anterofit/blob/proc_macro/examples/post_service_proc_macro.rs

कार्य

(dtolnay संपादित करें: चेकलिस्ट को ओपी तक ले जाया गया)

cc @nrc @petrochenkov @durka @Ralith

@jseyfried मैं एक ऐसे मुद्दे में भाग गया, जहां एक विरासत मैक्रो और एक ही नाम के साथ एक विशेषता को एक ही दायरे में आयात किया जाता है, तो विशेषता का उपयोग करने का प्रयास एक त्रुटि फेंकता है कि मैक्रोज़ को विशेषताओं के रूप में उपयोग नहीं किया जा सकता है। क्या हम यह काम कर सकते हैं ताकि दोनों एक ही दायरे में हो सकें और इरादा के अनुसार इस्तेमाल किया जा सके?

@abonander सभी मैक्रोज़ (बैंग, एट्रिब्यूट, और व्युत्पन्न) समान नामस्थान साझा करते हैं, इसलिए हम एक ही नाम के साथ एक ही दायरे में दो अलग-अलग मैक्रोज़ का उपयोग नहीं कर सकते हैं। हालांकि, हम उस त्रुटि संदेश में सुधार कर सकते हैं -- क्या आप कोई समस्या खोल सकते हैं?

क्षमा करें मुझे पार्टी में देर हो रही है। मैं एएसटी के बजाय टोकन को बेनकाब करने की दिशा से खुश हूं, लेकिन मुझे आरएफसी में प्रस्तावित विशिष्ट TokenStream एपीआई के बारे में कुछ चिंताएं हैं:

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,
}

यह स्पष्ट नहीं है कि क्या यह एपीआई एक पूर्ण योजना के रूप में थी जिसे आरएफसी के विलय के समय स्वीकार किया गया था, या बाद में काम करने के लिए सिर्फ एक उदाहरण था।

आम तौर पर, यह मैक्रोज़ के बाहर कंपाइलर द्वारा स्वीकार किए गए "सामान्य" रस्ट सिंटैक्स से बहुत दूर लगता है। जबकि कुछ मैक्रोज़ कुछ एड-हॉक डोमेन-विशिष्ट भाषा को पार्स करना चाहते हैं, अन्य "वास्तविक जंग" सिंटैक्स को पार्स करना चाहते हैं और इसे समझ सकते हैं।

1. (मामूली) मुझे नहीं लगता कि Eof जरूरी है। एक Iterator का उपयोग संभवतः TokenStream से अधिक पुनरावृति के लिए किया जाएगा और Iterator::next पहले से ही पुनरावृत्ति के अंत का संकेत देने के लिए None लौटाता है।

2. (मामूली) मुझे नहीं लगता कि Exclamation , Dollar , या Semicolon आवश्यक हैं। उदाहरण के लिए Punctuation('!') पर मिलान करना अधिक कठिन नहीं है।

3. (मामूली) जैसा कि अन्य ने आरएफसी पीआर में उल्लेख किया है, हम उन टिप्पणियों को छोड़ना चाहेंगे जो दस्तावेज़-टिप्पणियां नहीं हैं। (कोई भी उपयोग मामला जो टिप्पणी को संरक्षित करना चाहता है, संभवतः व्हाइटस्पेस को भी संरक्षित करना चाहता है।)

4. जहां तक ​​​​मैं कह सकता हूं, बहु-चरित्र ऑपरेटरों के साथ क्या करना है (जो शायद प्रत्येक टोकन होना चाहिए) अभी भी एक खुला प्रश्न है। पीआर टिप्पणियों में एक संभावित समाधान पर चर्चा की गई है, लेकिन ऐसा लगता है कि इसे आरएफसी टेक्स्ट में नहीं बनाया गया है।

5. संख्या अक्षर गायब हैं। क्या मैक्रोज़ को शाब्दिक मूल्यांकन करने के लिए [Punct('1'), Punct('_'), Punct('2'), Punct('3'), Punct('4'), Punct('.'), Punct('5'), Punct('e'), Punct('6')] को स्वयं पार्स करना चाहिए? वे ऐसा करने के लिए str::parse::<f32> का उपयोग भी नहीं कर सकते हैं, क्योंकि यह जिस सिंटैक्स को स्वीकार करता है वह रस्ट शाब्दिक सिंटैक्स के समान नहीं है (उदाहरण के लिए, बीच में _ हो सकता है)।

   मुझे लगता है कि यहां स्थिरता की चिंता है। क्या हम u128 / i128 (और संभवतः भविष्य में f128 , u256 ,…) टोकन एपीआई? इसे संभव बनाने का एक तरीका यह हो सकता है:

   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. // शब्द यूनिकोड मानक अनुलग्नक 31 द्वारा परिभाषित किया गया है -

   इस परिभाषा को उससे अधिक सटीक होने की आवश्यकता है। UAX 31 पहचानकर्ता सिंटैक्स के कुछ भिन्न रूपों को निर्दिष्ट करता है, और उनमें से किसी को भी "शब्द" नहीं कहा जाता है। लेकिन हम जो सटीक भिन्नता चाहते हैं उसे चुनना इस समय गैर-ASCII पहचानकर्ता फीचर-गेटेड क्यों

   इसके बजाय, मुझे लगता है कि इसे "जो कुछ भी वर्तमान कंपाइलर पहचानकर्ता या कीवर्ड के रूप में स्वीकार करता है" के रूप में परिभाषित किया जाना चाहिए (जो प्रति # 28979 बदल सकता है)। शायद libmacro में pub fn is_identifier(&str) -> bool सार्वजनिक API के साथ।

7. यूनिकोड स्ट्रिंग्स और बाइट स्ट्रिंग अक्षर एक एकल टोकन संस्करण साझा करते हैं, जो मुझे लगता है कि गलत है क्योंकि उनके मूल्यों के स्मृति प्रतिनिधित्व के विभिन्न प्रकार हैं ( str बनाम [u8] )। यह भी स्पष्ट नहीं है कि text: Symbol घटक का उद्देश्य स्रोत कोड का शाब्दिक टुकड़ा होना है या बैकस्लैश एस्केप को हल करने के बाद मूल्य। मुझे लगता है कि यह निश्चित रूप से बाद वाला होना चाहिए। (तुलना के लिए, Char(char) के बाद से उत्तरार्द्ध हो गया है \u{A0} एक से अधिक लेता है char सचमुच प्रतिनिधित्व करते हैं।)

उच्च स्तरीय मैक्रोज़ लिखने का एक और तरीका मैक्रोज़ की तरह लिस्प का उपयोग करना होगा, लेकिन इसके लिए पूरे जंग के लिए एस-एक्सप्रेशन प्रतिनिधित्व की आवश्यकता होगी।

@ साइमन सैपिन ,

जैसा कि अन्य ने आरएफसी पीआर में उल्लेख किया है, हम उन टिप्पणियों को छोड़ना चाहेंगे जो दस्तावेज़-टिप्पणियां नहीं हैं। (कोई भी उपयोग मामला जो टिप्पणी को संरक्षित करना चाहता है, संभवतः व्हाइटस्पेस को भी संरक्षित करना चाहता है।)

कृपया मत करो। मेरे पास एक उपयोग-मामला है जहां मैं उपयोग करना चाहता हूं (हालांकि संरक्षित नहीं है-वे इसके बजाय एक अलग संकलन उत्पाद में लिखे जाएंगे) वाक्यविन्यास में टिप्पणियां।

विशेष रूप से, मैं अनुवाद मैक्रोज़ बनाना चाहता हूं जो एक अलग स्रोत फ़ाइल से स्ट्रिंग के अनुवाद लोड करेगा और मैं डीबग बिल्ड में उप-उत्पाद के रूप में अनुवादित होने के लिए स्ट्रिंग की एक सूची जेनरेट करना चाहता हूं। और उस सूची में उत्सर्जित होने वाली टिप्पणियों को शामिल करने का एक तरीका होना चाहिए (रस्ट-लोकेल/रस्ट-लोकेल # 19)। तो टिप्पणी सिंटैक्स का उपयोग करना समझ में आता है और मैक्रो को उन्हें देखने की जरूरत है।

मैं उस पोस्ट के अन्य बिंदुओं से सहमत हूं।

@ जान-हुडेक
भले ही हमारे पास TokenKind::Comment , फिर भी आप लगातार टोकन के बीच स्पैन की सामग्री को देखकर टिप्पणियों का उपयोग कर सकते हैं।

मुझे लगता है कि हमारे पास TokenKind::Comment नहीं होना चाहिए ताकि प्रक्रियात्मक मैक्रोज़ को टिप्पणियों को अनदेखा करने के लिए प्रोत्साहित किया जा सके ताकि उपयोगकर्ता शब्दार्थ को बदलने की चिंता किए बिना मैक्रो इनवोकेशन में टिप्पणियां जोड़ने के लिए स्वतंत्र हों।

@ jan-hudec क्या कोई कारण है कि विशेषताएँ आपके समाधान के साथ काम नहीं करेंगी?

@abonander , विशेषताएँ बिल्कुल समझ में नहीं आती हैं। अनुवाद योग्य स्ट्रिंग्स शाब्दिक के रूप में कार्य करती हैं, आइटम के रूप में नहीं। लेकिन संकलन के दौरान उन्हें निकालना केवल सुविधा के लिए होगा - इसे हमेशा अलग पार्सिंग के रूप में किया जा सकता है (और वास्तव में, ऐसा हो सकता है, क्योंकि मुझे टोकरे में उनमें से _all_ देखने की आवश्यकता है और वृद्धिशील संकलन उसे तोड़ देगा)।

मैं एक प्रक्रियात्मक मैक्रो बनाना चाहता हूं जो सर्डे के व्युत्पन्न पर आधारित है (और इसलिए सीधे सर्डे टोकनस्ट्रीम फ़ंक्शंस को कॉल करता है) लेकिन यह कहने का कोई तरीका नहीं है कि मैं एक प्रक्रियात्मक मैक्रो की बजाय लाइब्रेरी के रूप में सेर्डे प्राप्त करना चाहता हूं। यह मैक्रोज़ प्राप्त करने के लिए विशिष्ट नहीं है, मैं 'सामान्य' प्रक्रियात्मक मैक्रोज़ के लिए भी इसी तरह की चीज देख सकता हूं।

मेरा एकमात्र समाधान अभी serde_derive को फोर्क करना प्रतीत होता है।

समस्या यह त्रुटि संदेश rustc से है:

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

इसे हटाना और इसे काम करना आसान है, लेकिन कुछ जटिलता भी है जो मुझे यकीन नहीं है कि कैसे हल किया जाए - एक प्रक्रियात्मक मैक्रो क्रेट संभवतः दोनों एक अन्य प्रक्रियात्मक मैक्रो क्रेट से प्राप्त प्रो-मैक्रो का उपयोग करना चाहता है, साथ ही साथ डाउनस्ट्रीम उपयोगकर्ता के लिए व्युत्पन्न उत्पन्न करने के लिए कार्यों को कॉल करना। वो कैसा लगता है? क्या इस समय भी ऐसा ही कुछ है, जहां खाने वाले टोकरे के अनुरोध पर एक टोकरा को दो अलग-अलग तरीकों से जोड़ा जा सकता है?

@aidanhs

एक प्रक्रियात्मक मैक्रो क्रेट संभवतः दोनों एक अन्य प्रक्रियात्मक मैक्रो क्रेट से प्राप्त प्रो-मैक्रो का उपयोग करना चाहता है, साथ ही साथ डाउनस्ट्रीम उपयोगकर्ता के लिए व्युत्पन्न उत्पन्न करने के लिए फ़ंक्शंस को कॉल करना चाहता है। वो कैसा लगता है?

आप proc-macro टोकरे से फ़ंक्शंस (या प्रक्रियात्मक मैक्रोज़ के अलावा कुछ भी) तक नहीं पहुँच सकते। यदि आप TokenStream -> TokenStream फ़ंक्शंस और संबंधित प्रक्रियात्मक मैक्रोज़ का उपयोग करना चाहते हैं, तो आपको TokenStream -> TokenStream फ़ंक्शंस को एक अलग, गैर- proc-macro क्रेट में रखना होगा, और फिर एक proc-macro टोकरा जो सिर्फ उन कार्यों को सौंपता है।

यह RFC ज्यादातर #40939 भूमि पर लागू किया जाएगा।

proc_macro लेखकों को क्रेट रूट पर extern crate foo; शामिल करने की आवश्यकता के बिना पूर्व निर्धारित क्रेट में आइटम का उपयोग करने वाले विस्तार बनाने के लिए एक तरीका प्रदान करें foo

मान लीजिए कि मैं एक एकल टोकरा प्रस्तुत करना चाहता हूं, जिसमें गैर-मैक्रो आइटम और एक प्रक्रियात्मक मैक्रो दोनों शामिल हैं जो उक्त वस्तुओं को संदर्भित करता है। जब #40939 भूमि, क्या यह तीन-टोकरा पैटर्न इस लक्ष्य को प्राप्त करने का मुहावरेदार तरीका होगा?

1. सभी गैर-मैक्रो आइटम foo_runtime
2. में प्रक्रियात्मक मैक्रो लागू foo_macros , में प्रतीकों की चर्चा करते हुए foo_runtime आवश्यक के रूप में
3. एक अंतिम "मुखौटा" टोकरा जोड़ें foo कि pub use s foo_runtime और foo_macros से आइटम हैं
   
   
   
   • यह एकमात्र टोकरा है जिसे उपयोगकर्ता सीधे आयात करेगा
   
   
   • यह काम करता है क्योंकि स्वच्छता प्रणाली मैक्रो को सही टोकरा की ओर इंगित करने के लिए ठीक करती है
   
   

मैं पूछता हूं क्योंकि मेरे उपयोग के मामले में दो बक्से आयात करना शामिल है, और यह प्रयोज्य के लिए बहुत अच्छा होगा यदि मैं सिर्फ एक के साथ दूर हो सकता हूं।

@lफेयरी मुझे लगता है कि एक "दो-टोकरा" पैटर्न मुहावरेदार तरीका होगा:

1. सभी गैर-मैक्रो आइटम foo
2. में प्रक्रियात्मक मैक्रो लागू foo_macros , में प्रतीकों की चर्चा करते हुए foo आवश्यक है, जैसे के रूप में

#[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 : क्या आप जानते हैं कि यह पुन: निर्यात चाल कस्टम व्युत्पन्न के साथ भी काम करती है? क्योंकि इन क्रेटों में किसी भी वस्तु का निर्यात न कर पाने की ठीक वैसी ही सीमा होती है।

@ कॉलिन-कीगल
कस्टम व्युत्पन्न क्रेट केवल मैक्रो क्रेट की खरीद करते हैं जो केवल #[proc_macro_derive] s होते हैं।
#[feature(proc_macro)] , आप सामान्य क्रेटों में कस्टम व्युत्पन्न पुन: निर्यात कर सकते हैं, ठीक वैसे ही जैसे आप अन्य प्रो मैक्रोज़ को पुनः निर्यात कर सकते हैं।

@jseyfried मैं इस समय की स्थिति से अवगत हूं, मैंने सवाल उठाया क्योंकि मुझे नहीं लगता कि यह आदर्श है और इसके बारे में चर्चा करने की उम्मीद है। जिस स्थिति में आप वर्णन करते हैं, किसी अन्य क्रेट के प्रक्रियात्मक मैक्रोज़ को 'प्रतिनिधि'/पुन: उपयोग करना मैक्रो लेखक (इस मामले में, सेर्डे) को अपने प्रक्रियात्मक मैक्रोज़ को दो क्रेट में विभाजित करने के लिए आश्वस्त करने का विषय बन जाता है। अगर मैं सामान्य कार्यों की तरह प्रक्रियात्मक मैक्रोज़ को कॉल कर सकता हूं, तो अपस्ट्रीम क्रेट लेखक को यह जानने की भी आवश्यकता नहीं है कि मैं उनके क्रेट का उपयोग कर रहा हूं।

उस ने कहा, मैं संगतता खतरे को पहचानता हूं - मैक्रो द्वारा उत्पन्न सटीक टोकनट्री स्थिर इंटरफ़ेस का हिस्सा बन जाता है, इसलिए यदि सेर्डे बदलता है कि वे पैच संस्करण में Derive कैसे उत्पन्न करते हैं और मैंने एक नाजुक मैक्रो लिखा है, मेरा मैक्रो मेरे क्रेट के हर एक नए उपयोगकर्ता के लिए टूट जाएगा (वर्तमान मामले में एक नाजुक मैक्रो के विपरीत, जहां सबसे खराब स्थिति में यह केवल विशिष्ट इनपुट के लिए काम करेगा, लेकिन लगातार)।

@jseyfried

क्या यह मौजूदा कार्गो डिप्लिस्ट से foo खींचता है? यह बुरा लगता है (यानी क्या यह कुछ विशेष रूप से बेवकूफी भरा काम करेगा यदि वर्तमान बाइनरी में foo नाम के 2 क्रेट जुड़े हुए हैं?)

@aidanhs यह एक बड़ा भाषा परिवर्तन/जोड़ होगा जो अपने स्वयं के आरएफसी को वारंट करेगा।

@ एरियलब1

क्या यह मौजूदा कार्गो डिप्लिस्ट से foo खींचता है? यह बुरा लगता है

हाँ - दुख की बात है कि उद्धृत extern crate नाम स्वच्छ नहीं हैं, अर्थात संकल्प इस बात पर निर्भर करता है कि कौन से क्रेट नाम उस दायरे में हैं जहां प्रक्रियात्मक मैक्रो का उपयोग किया जाता है। हम पुन: निर्यात चाल का उपयोग करके इसे कम कर सकते हैं (यानी foo_macros को foo पुन: निर्यात करना ताकि हम जान सकें कि foo दायरे में होगा), लेकिन यह सुरक्षा नहीं करता है foo नाम के दो क्रेट होने पर अस्पष्टता त्रुटियों के विरुद्ध।

मुझे लगता है कि यहां सबसे अच्छा समाधान चरण 1 (यानी लक्ष्य wrt होस्ट बनाम लक्ष्य) निर्भरता को Cargo.toml लिए proc-macro --target-extern कमांड लाइन तर्क के माध्यम से जोड़ना है। यह हमें extern crate नामों को quote! दायरे में स्पष्ट रूप से सूचीबद्ध करने की अनुमति देगा।

@jseyfried

विचार यह है कि एक प्रो-मैक्रो क्रेट के "लक्ष्य" मेटाडेटा में निर्भरता होगी, है ना?

@ arielb1 हाँ, बिल्कुल।

यह RFC ज्यादातर #40939 भूमि पर लागू किया जाएगा।

@jseyfried जैसा कि पीआर भूमि पर स्थिर होने के लिए तैयार है? यदि नहीं, तो स्थिरीकरण को अवरुद्ध करने वाला क्या रहेगा? मैं नहीं चाहता कि यह अभी तक एक और विशेषता हो, जहां ऐसा लगता है कि हमें लागू करने की दिशा में 95% रास्ता मिल गया है और लोग सभी उत्साहित हो जाते हैं, और फिर चीजें एंटीक्लेमेक्टिक रूप से बंद हो जाती हैं।

के रूप में, जब वह पीआर लैंड करता है तो स्थिर होने के लिए तैयार होता है?

नहीं, हम extern crate नामों के लिए स्थिरीकरण और शायद भविष्य के प्रूफ हाइजीन से पहले एपीआई के साथ कुछ अनुभव प्राप्त करना चाहते हैं (अर्थात इस मुद्दे को संबोधित @ एरियलब1 ने बताया)।

हम शायद इस एपीआई में महत्वपूर्ण बदलाव करना चाहेंगे; @eddyb ने सभी टोकन ट्री के लिए OpKind को सामान्य बनाने का प्रस्ताव/विचार किया है। साथ ही, हम बदल सकते हैं कि हम दस्तावेज़ टिप्पणियों, फ़्लोटिंग पॉइंट अक्षर आदि को कैसे संभालते हैं। कुल मिलाकर, इस पीआर में एपीआई अभी तक स्थिर होने पर विचार करने के लिए पर्याप्त परिपक्व नहीं है।

@bstree दुख की बात है कि आरएफसी https://github.com/rust-lang/rfcs/ पुल/1913

@ est31 स्थगित, और अधिक पसंद - इस एपीआई के साथ एक छोटे से अनुभव के बाद हम एक सबसेट पर सहमत हो सकते हैं कि हम स्थिर को फास्ट-ट्रैक करने के लिए सहमत हो सकते हैं।

String -आधारित API घोषणात्मक मैक्रोज़ 2.0 के साथ बुरी तरह से इंटरैक्ट करता है और आज मैक्रोज़ 2.0 के बिना और केवल #[derive] s के साथ भी सीमित कर रहा है। हम String आधारित API के प्रसार से यथासंभव बचना चाहते हैं ताकि लोगों द्वारा मैक्रोज़ 2.0 में माइग्रेट करने की समस्या से बचा जा सके।

मैंने #[proc_macro_attribute] लिए एक मुद्दा खोला है जो प्रतीत होता है कि विशेषता विधियों पर विस्तार नहीं हो रहा है (शायद सामान्य रूप से विशेषता आइटम?)

चूंकि यह अब proc_macro क्रेट और इसके नए एपीआई के लिए ट्रैकिंग समस्या है, मैंने सोचा कि मैं कुछ विचार भी लिखूंगा। मैंने proc-macro2 नामक एक टोकरा प्रकाशित किया है जिसका उद्देश्य proc_macro क्रेट इन-ट्री के समान होना है, सिवाय इसके कि यह स्थिर जंग पर संकलन करने की क्षमता प्रदान करता है। इसके बाद यह बेहतर अवधि की जानकारी का लाभ प्राप्त करने के लिए रात के जंग पर संकलन करने के लिए एक सुविधा का उपयोग करने की क्षमता भी रखता है। उस पुस्तकालय का उद्देश्य syn जैसे अन्य पुस्तकालयों के लिए नींव बनना है, और syn के विकास में हमें कुछ कमियां मिलीं जिन्हें हम सीधे proc_macro में संबोधित करना चाहते हैं:

• कुछ प्रकार के शाब्दिकों के लिए कोई Literal कंस्ट्रक्टर नहीं है। यह स्ट्रिंगीकरण के माध्यम से पार्सिंग के बाद चारों ओर काम किया जाता है, लेकिन स्ट्रिंग एपीआई के माध्यम से जाने के बिना इन्हें सीधे बनाने में सक्षम होना बहुत अच्छा होगा।
  
  
  
  • कच्चे तार - r###" foo "###
  
  
  • कच्चे बाइट स्ट्रिंग्स - rb#" foo "#
  
  
  • बाइट शाब्दिक - b'x'
  
  
  • डॉक्टर टिप्पणियाँ - ये वर्तमान में Literal टोकन के रूप में दर्शायी जाती हैं।
  
  
• Literal का निरीक्षण करने और उसका मूल्य निकालने का कोई तरीका नहीं है। अभी हम to_string शाब्दिक क्रेट पर भरोसा कर रहे हैं और इसे फिर से पार्स कर रहे हैं, लेकिन सिद्धांत रूप में यह जानकारी पहले से ही Literal में संग्रहीत है और यह करने में सक्षम होना अच्छा होगा इस तक पहुंचें।
• कुछ मामलों में टोकन की मैपिंग को थोड़ा अजीब माना जा सकता है। अर्थात् अभी डॉक्टर टिप्पणियाँ मानचित्र को Literal प्रकार पर मैप करती हैं।

मेरा मानना ​​​​है कि यहां से कर दिया गया है।

जब साथ परीक्षण मैं एक टूटना का सामना करना पड़ा #![feature(proc_macro)] है कि कस्टम की व्युत्पत्ति प्रभावित करता है #[proc_macro_derive(foo, attributes(foo))] । यानी, एक कस्टम व्युत्पन्न जिसमें एक विशेषता का नाम होता है जो कि कस्टम व्युत्पन्न के समान होता है। ऐसा ही एक टोकरा है मेरा - व्युत्पन्न-त्रुटि-श्रृंखला, जिसमें #[derive(error_chain)] #[error_chain(...)] struct ErrorKind { ... } । दूसरा व्युत्पन्न-नया है, जिसमें #[derive(new)] #[new] struct S; । मुझे नहीं पता कि क्या अन्य हैं।

इस तरह के कोड के लिए, कंपाइलर दूसरी विशेषता पर शिकायत करता है कि "foo" is a derive mode । क्या यह जानबूझकर है या इसे ठीक किया जा सकता है? अगर जानबूझकर मुझे अपने कस्टम व्युत्पन्न का नाम बदलकर ErrorChain या कुछ और करने के लिए तैयार करने की आवश्यकता है।

@ अर्नवियन
यह सामान्य रूप से जानबूझकर था - चूंकि proc_macro_attribute s को व्युत्पन्न होने से पहले विस्तारित किया जाना चाहिए, यदि 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 नहीं माँग रहा था। यह दो proc_macro_derive s में से एक से सिर्फ एक उदाहरण था जिसके बारे में मुझे पता है कि इससे टूट गया है।

@Arnavion क्षमा करें, मेरी अंतिम टिप्पणी स्पष्ट नहीं थी - मेरा मतलब विशेष-मामला new विशेष रूप से नहीं था, लेकिन #[derive(some_macro)] #[some_attr] struct S; अनुमति देने के लिए जब some_attr एक proc_macro_derive समाधान करता है some_attr समाधान proc_macro_attribute , तो यह एक अस्पष्टता त्रुटि होनी चाहिए; आज, यह एक अस्पष्टता त्रुटि है यदि some_attr किसी भी मैक्रो को हल करता है।

हां, मुझे यह मिल गया।

( मुझे आशा है कि इस तरह के प्रश्न के लिए यह सही जगह है। )

इसकी स्थिति क्या है?

• [ ] proc_macro लेखकों को एक पूर्व निर्धारित क्रेट में आइटम का उपयोग करने वाले विस्तार बनाने के लिए एक रास्ता प्रदान करें foo मैक्रो उपयोगकर्ता को क्रेट रूट पर extern crate foo; शामिल करने की आवश्यकता के बिना (पीआर #40939 )

पीआर उतर गया है, लेकिन बॉक्स अभी भी चेक नहीं किया गया है। @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 No: $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) स्थिर में काम करता है। मैं भी स्पष्ट रूप से प्रलेखित किया है कि उपयोगकर्ताओं को बधाई देने के लिए उपयोग करने के लिए #[macro_use] के साथ error-chain टोकरा आयात करने से पहले इसे आयात करने की आवश्यकता होगी derive-error-chain ।

लेकिन फिर भी अगर मैं करने के लिए कस्टम निकाले जाते हैं नाम बदलने ErrorChain बनाने के लिए (1) के साथ काम proc_macro सुविधा (जो पहले से ही स्थिर कोड के लिए एक को तोड़ने परिवर्तन है):

#![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 `error_chain` may not be used in attributes क्योंकि macro_rules मैक्रो स्पष्ट रूप से ओवरराइड होने के बजाय कस्टम व्युत्पन्न द्वारा पंजीकृत विशेषता के साथ संघर्ष करता है पहले मामले में।

इसलिए मुझे कस्टम व्युत्पन्न और इसकी विशेषता दोनों का नाम बदलना होगा। कस्टम व्युत्पन्न (प्रत्येक एनम पर एक) की तुलना में विशेषता बहुत अधिक (एनम के प्रत्येक संस्करण पर एक) का उपयोग करती है, इसलिए यह मेरी अपेक्षा से एक बड़ा ब्रेकिंग परिवर्तन है। मैं समझता हूं कि यह मेरे अपने निर्माण की एक मुश्किल स्थिति है (कस्टम व्युत्पन्न और इसकी विशेषता के लिए macro_rules मैक्रो के नाम का पुन: उपयोग करना), लेकिन यह भी कोड है जो स्थिर रूप से संकलित हो रहा है क्योंकि कस्टम व्युत्पन्न थे स्थिर हो गया, इसलिए मेरे पास यह सोचने का कोई कारण नहीं था कि छह महीने बाद कोई समस्या होगी।

क्या इसे शायद इसलिए बनाया जा सकता है ताकि कस्टम व्युत्पन्न की विशेषताएँ macro_rules मैक्रोज़ को ओवरराइड कर दें जैसे कि कस्टम व्युत्पन्न स्वयं macro_rules मैक्रोज़ को ओवरराइड करता है? असल में मैं नहीं देखता कि उनके बीच कोई अस्पष्टता कैसे हो सकती है, लेकिन मुझे लगता है कि यह वही कारण है जब एक ही नाम के कस्टम व्युत्पन्न के बाद macro_rules मैक्रो आयात किया जाता है - कि सभी मैक्रोज़ में डाल दिया जाता है वे किस प्रकार के मैक्रो हैं, इस पर विचार किए बिना समान नामस्थान।

क्या प्रो मैक्रोज़ के बारे में बात करने के लिए कुछ कम औपचारिक "स्थान" है? एक #rust-proc-macro आईआरसी चैनल की तरह? मैं समय-समय पर इस सुविधा के बारे में छोटे-छोटे प्रश्न पूछना पसंद करूंगा, लेकिन इस धागे को स्पैम करना गलत लगता है: देखें_नो_ईविल: और #rust चैनल में, अधिकांश लोगों ने प्रो-मैक्रोज़ के साथ काम नहीं किया है और विशेष रूप से नया proc_macro एपीआई (चूंकि यह अस्थिर और सभी है)। तो: इस विषय पर चर्चा करने के लिए कोई विचार?

@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

क्या इस घबराहट को एक डमी "सत्र" बनाने के साथ प्रतिस्थापित करना संभव/वांछनीय होगा? या शायद एक बनाने के लिए एक सार्वजनिक एपीआई (स्थिरीकरण के पथ के साथ) जोड़ें?

क्या किसी ने अन्य प्रणालियों के मैक्रोज़ पर साहित्य को देखा है? मैं इस पर लोगों के विचार जानना चाहता हूं। मैं यहां स्कीम के बारे में बात करूंगा, क्योंकि मैं इससे सबसे ज्यादा परिचित हूं।

मैं व्यक्तिगत रूप से अपने स्वयं के प्रोजेक्ट पर R7RS योजना के लिए syntax-rules को लागू करने पर काम कर रहा हूं, और मैंने पाया है कि syntax-case अस्वच्छ और स्वच्छ मैक्रो सिस्टम ( defmacro दोनों का समर्थन करने के लिए आधार बना सकता है। और syntax-rules )। जीएनयू गुइल ऐसा करता है। syntax-case फेंडर के लिए भी समर्थन है जो सिंटैक्स ऑब्जेक्ट सूचियों पर अतिरिक्त विधेय सत्यापन कर सकता है (या, योजना में TokenStream की तर्ज पर कुछ)। मैं देख सकता हूं कि Mark पर काम किया जा रहा है, और ऐसा लगता है कि यह दायरे के सेट के रूप में बाइंडिंग से प्रेरित है।

साथ ही, क्या हमें यह भी चर्चा करनी चाहिए कि क्या संकलन-समय पर मनमानी गणना का समर्थन किया जाना चाहिए? रैकेट वास्तव में चीजों के लिए एक संपूर्ण "चरण" दृष्टिकोण लेता है, ऐसा प्रतीत होता है, begin-for-syntax मैक्रो विस्तार के दौरान संकलन-समय स्तर पर परिभाषाओं और गणना (?) के लिए अनुमति देता है। .

योजना में (datum->syntax <thing-to-copy-scope-from> <thing-to-apply-scope-to>) साथ स्वच्छता पर नियंत्रण बहुत संभव है, जिससे आप मैक्रो के दायरे से बच सकते हैं और इसके बजाय तत्काल दायरे से बाहर किसी वस्तु का दायरा ले सकते हैं।

इस उदाहरण को द स्कीम प्रोग्रामिंग लैंग्वेज, तीसरा संस्करण से लें। आर. केंट डाइबविग द्वारा (चेज़ स्कीम, अब सिस्को सिस्टम्स में): http://www.scheme.com/tspl3/syntax.html । उदाहरण (include "filename.scm") को syntax-case मैक्रो के रूप में दिखाता है, और दुभाषिया को फ़ाइल से पढ़ने और मूल्यांकन जारी रखने के लिए रनटाइम सेट करने के लिए मैक्रो का उपयोग करने की अनुमति देता है। यहां गहरा सवाल यह है कि क्या हम मैक्रो-मैक्रो सिस्टम को मैक्रो-विस्तार समय पर ऐसी चीजों को होने की अनुमति देना चाहते हैं, और फ़ाइल आयात को ट्रिगर करने जैसे संकलन-समय गणनाओं को ट्रिगर करना चाहते हैं (हालांकि, यह प्रत्यक्ष कंपाइलर कार्यक्षमता में होता है, तो शायद हम ऐसा नहीं करना चाहते)।

मैक्रोज़ की सीमाएं क्या होनी चाहिए? मुझे लगता है कि जंग, इसके संकलन समय में कटौती करना चाहता है, संकलन-समय मूल्यांकन को प्रतिबंधित करना चाहता है (और विशेष रूप से अनंत लूप से बचें)। रैकेट ने छोटे टुकड़ों में लिस्प में संदर्भित चरणों के साथ "तैयार करने वालों और विस्तारकों का टॉवर" दृष्टिकोण लिया है। क्या हम फ़ाइल I/O और सीमित पुनरावर्ती गणना करने के लिए संकलन-समय API तक पहुंच की अनुमति देना चाहते हैं? क्या हमें ऐसी चीजों की अनुमति देनी चाहिए जैसे प्रक्रियात्मक मैक्रो सीएसवी स्प्रेडशीट स्पेक्स को स्विच स्टेटमेंट में बदलने में सक्षम हों?

मुझे अन्य प्रणालियों के बारे में सुनना अच्छा लगेगा! मैंने सुना है कि टेम्पलेट हास्केल के पास अपने एएसटी का प्रतिनिधित्व करने के लिए अच्छी तरह से परिभाषित प्रकारों के साथ एक दिलचस्प दृष्टिकोण है, और हास्केल में आलस्य नियंत्रण संरचनाओं के लिए मैक्रोज़ के कई उपयोगों को प्रतिस्थापित कर सकता है।

क्षमा करें यदि मैं लाइन से बाहर निकल रहा हूँ।

मैक्रोज़ की सीमाएं क्या होनी चाहिए?

इस मुद्दे में चर्चा की गई प्रक्रियात्मक मैक्रोज़ के लिए, कोई नहीं . एक प्रक्रियात्मक मैक्रो एक कंपाइलर एक्सटेंशन है। यह कुछ सी ++ कोड ले सकता है, इसे क्लैंग के माध्यम से चला सकता है और परिणामी वस्तु को संकलन में जोड़ सकता है। यह कुछ एसक्यूएल ले सकता है, संबंधित परिणाम प्रकार खोजने के लिए डेटाबेस से पूछताछ कर सकता है और उचित परिणाम सेट उत्पन्न कर सकता है। वे वास्तविक उपयोग के मामले हैं जो लोग करना चाहते हैं!

ध्यान दें, कि रस्ट में एक और मैक्रो सिस्टम है। यह अद्यतन RFC 1584 के रूप में स्वीकृत किया गया था और कार्यान्वयन को https://github.com/rust-lang/rust/issues/39412 द्वारा ट्रैक किया जाता है

@VermillionAzure , आपके द्वारा संदर्भित योजना प्रपत्रों को त्वरित रूप से देखने से:

macro_rules , और उनका अद्यतन प्रति RFC 1584 , syntax-rules । यदि आपके पास उन्हें बढ़ाने के लिए सुझाव हैं, तो https://github.com/rust-lang/rust/issues/39412 शायद उस पर चर्चा करने के लिए सबसे अच्छी जगह है।

प्रो-मैक्रोज़, जिसके बारे में यह मुद्दा है, define-syntax के सामान्य रूप की तरह हैं। और यह RFC ( 1566 ) जानबूझकर syntax-case जैसी किसी भी चीज़ को परिभाषित नहीं करता है। टोकन स्ट्रीम को बदलने के लिए फ़ंक्शन को कॉल करने के लिए केवल एक इंटरफ़ेस।

इंटरफ़ेस को इस तरह से परिभाषित किया गया है कि syntax-case जैसा कुछ एक अलग क्रेट (लाइब्रेरी) में लागू किया जा सकता है और इरादा इसे इस तरह से करना है। यदि आप इतने इच्छुक हैं, तो बेझिझक इधर-उधर खेलें। एपीआई का उपयोग करना कितना आसान या कठिन है, इस पर किसी भी प्रोटोटाइप और रिपोर्ट का निश्चित रूप से स्वागत किया जाएगा।

मुझे लगता है कि यह विचार था, मैक्रोज़ जैसे कार्यों को परिभाषित करना, जैसे कि लिस्प में, लेकिन मैक्रो होने पर, जो मैक्रो को लौटाता है, जो 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 नहीं, ऐसा नहीं लगता। मैं सिर्फ देखने के लिए कि योजना मैक्रो एक प्रासंगिक विचार चर्चा में जोड़ने के लिए किया जाएगा चाहता था - यह स्पष्ट है कि ज्यादा से ज्यादा शक्तिशाली हो के बाद से प्रक्रियात्मक मैक्रो करना है syntax-case योजना में मैक्रो प्रणाली है कि यह मामूली बात है यहां प्रदान की गई मनमानी शक्ति के संदर्भ में सभी मैक्रो सिस्टम को लागू करने के लिए।

@ jan-hudec क्या किसी भी प्रकार की सुरक्षा गारंटी के बिना किसी भी मनमानी गणना को एक कंपाइलर एक्सटेंशन के रूप में अनुमति देना बुद्धिमानी है? मैं इस विचार से पूरी तरह प्रभावित हूं कि प्रक्रियात्मक मैक्रो यहां इतने शक्तिशाली होने जा रहे हैं, लेकिन क्या रस्ट के कोई भी संभावित उपयोगकर्ता इसे पैकेज का उपयोग करने के लिए एक नकारात्मक पहलू मानेंगे? मैं किसी भी तरह से सुरक्षा विशेषज्ञ नहीं हूं, लेकिन कंपाइलर एक्सटेंशन के भीतर उपयोग किए जाने वाले किसी भी पुस्तकालय में कमजोरियों को आसानी से जंग कंपाइलर को हमले वेक्टर में दुर्भावनापूर्ण रूप से बदलने के लिए उपयोग नहीं किया जा सकता है? इसके अतिरिक्त, यदि प्रक्रियात्मक मैक्रोज़ में प्रयुक्त पुस्तकालयों में कोई बग होता है (उदाहरण के लिए खराब सी लाइब्रेरी कोड द्वारा ट्रिगर किया गया segfault), तो क्या इसका मतलब यह है कि segfault ट्रिकल हो जाएगा और कंपाइलर को उचित त्रुटि संदेश के बिना विफल कर देगा?

क्या प्रक्रियात्मक मैक्रोज़ में होने वाली त्रुटियों को इस तरह से समाहित करने का कोई तरीका होगा कि यह संकलक के किसी अन्य हिस्से को प्रभावित न करे?

एक और विचार: प्रक्रियात्मक मैक्रोज़ कब निष्पादित होते हैं? यदि प्रक्रियात्मक मैक्रोज़ उस कोड के साथ इंटरैक्ट कर सकते हैं जिसके साइड इफेक्ट प्रासंगिक हो सकते हैं (उदाहरण के लिए एक स्टेटफुल बाहरी सर्वर के साथ संचार करना, बाहरी SQL डेटाबेस को बदलना, बाहरी सिस्टम में लॉग इन करने के लिए सुरक्षा कुंजी प्राप्त करना), तो इसका मतलब यह नहीं है कि किस क्रम में प्रक्रियात्मक मैक्रोज़ को संकलन प्रक्रिया द्वारा ट्रिगर किया जाता है, महत्वपूर्ण है?

@VermillionAzure कार्गो पैकेज में पहले से ही बिल्ड स्क्रिप्ट हो सकती हैं जो संकलन-समय पर मनमानी कोड निष्पादित करती हैं, इसलिए प्रक्रियात्मक मैक्रोज़ उस मोर्चे पर चीजों को और खराब नहीं करते हैं: आपको पहले से ही अपनी निर्भरताओं पर भरोसा करने की आवश्यकता है। (यह crates.io द्वारा अपरिवर्तनीय/एपेंड-ओनली होने के कारण कुछ आसान बना दिया गया है, और निर्भरता स्वचालित रूप से अपडेट नहीं हो रही है यदि आपके पास Cargo.lock फ़ाइल है: आपको केवल विशिष्ट संस्करणों पर भरोसा करने की आवश्यकता है।) और भले ही स्क्रिप्ट का निर्माण न किया हो मौजूद हैं, आपकी निर्भरता अभी भी स्वभाव से रन-टाइम पर मनमाना कोड निष्पादित कर सकती है। क्या संकलन-समय बहुत खराब है?

यह चर्चा मुझे एक संबंधित, लेकिन अलग समस्या के बारे में सोचने पर मजबूर करती है।

मान लीजिए कि एक टोकरा दो प्रो मैक्रो को परिभाषित करता है: foo!() एक अस्थायी फ़ाइल लिखता है, और bar!() उसी फ़ाइल को पढ़ता है। इस टोकरे का एक उपभोक्ता एक ही मॉड्यूल में foo!() और bar!() दोनों का आह्वान करता है। फिर, संकलन सफल होता है या नहीं यह इस बात पर निर्भर करेगा कि कौन सा foo!() या bar!() पहले विस्तारित किया गया है। यह आदेश कार्यान्वयन-परिभाषित है, और यदि पर्याप्त लोग इस तरह कोड लिखते हैं, तो वास्तविक मानक बन सकते हैं।

मुझे यकीन नहीं है कि यह कितना बड़ा मुद्दा है। बस इस बात को लेकर चिंतित हैं कि क्या इससे शैनैनिगन्स को ऑर्डर करने वाले स्ट्रक्चर फील्ड की पुनरावृत्ति होगी।

@SimonSapin

जबकि मैं आपकी स्थिति से सहमत हूं, मुझे यह बताना चाहिए कि संकलन-समय निष्पादन और रनटाइम निष्पादन के बीच एक महत्वपूर्ण अंतर है:

यह एक अलग खतरा मॉडल प्रदान करता है क्योंकि चीजों को एक बार संकलित किया जाता है और फिर कई मशीनों पर तैनात किया जाता है। (उदाहरण के लिए, लिनक्स डिस्ट्रो बिल्ड क्लस्टर पर अनुरक्षक असावधानी के साथ-साथ सैंडबॉक्सिंग की कमी का शोषण करना।)

@lफेयरी हां, यह ठीक वही मुद्दा है जो रैकेट के पास एक दशक पहले 2002 में था। रैकेट के सर्वोच्च योगदानकर्ता मैथ्यू फ्लैट ने "कम्पोज़ेबल एंड कंपाइलेबल मैक्रोज़: यू वांट इट व्हेन? " नामक एक पेपर बनाया। आर केंट डायबविग, जिन्होंने चेज़ योजना पर काम किया, उन्होंने "आर6आरएस पुस्तकालयों में लागू चरण" में पुस्तकालय/मॉड्यूल के मूल्यांकन में चरणों पर एक पेपर भी लिखा।

@SimonSapin संकलन-समय संभावित रूप से बहुत खराब हो सकता है। यदि आपका कंपाइलर बेतरतीब ढंग से दुर्घटनाग्रस्त हो जाता है या दुर्भावनापूर्ण व्यवहार करता है जो संकलक द्वारा ट्रिगर किया जाता है, तो मैं शर्त लगा सकता हूं कि कोई व्यक्ति एक विशाल Reddit पोस्ट लिखना समाप्त कर देगा जिसका शीर्षक होगा "रस्ट के मॉड्यूल स्वाभाविक रूप से असुरक्षित हैं" या ऐसा कुछ।

@VermillionAzure , मैंने लेखों को बहुत ध्यान से नहीं पढ़ा, लेकिन मुझे नहीं लगता कि वे चर्चा के लिए प्रासंगिक हैं, क्योंकि जंग के सामने आने वाले मुद्दे योजना के सामने आने वाले मुद्दों से बहुत अलग हैं।

योजना में एक पुस्तकालय दोनों कार्यों और मैक्रोज़ प्रदान कर सकता है, इसलिए संकलक को सही ढंग से क्रमबद्ध करना चाहिए कि कौन से कार्यों को संकलन-समय की आवश्यकता है और इसे रन-टाइम की आवश्यकता है। हालांकि, जंग में एक टोकरा या तो प्रक्रियात्मक मैक्रो, या रनटाइम फ़ंक्शन प्रदान करता है, इसलिए यह विभाजन (कुछ समय के लिए) स्पष्ट है।

(ध्यान दें कि रनटाइम फ़ंक्शन प्रदान करने वाला एक टोकरा नियम-आधारित (स्वच्छ) मैक्रोज़ भी प्रदान कर सकता है, लेकिन वे रस्ट में अलग तंत्र हैं)

@lफेयरी जिस समस्या के बारे में बात कर रहा है वह विस्तारक कार्यों के निष्पादन के आदेश में से एक है। जंग में, संकलन अलग-अलग फाइलों के लिए समानांतर हो सकता है और यह वृद्धिशील हो सकता है, इसलिए विस्तारकों के निष्पादन का क्रम अपरिभाषित है। लेकिन क्या दोनों में से कोई भी लेख वास्तव में इसका समाधान करता है? मैंने इसे नहीं देखा।

@ जान-हुडेक हाँ, मुझे लगता है कि तुम सही हो। लेकिन मूल्यांकन का क्रम निश्चित रूप से मायने रखेगा यदि संकलन-समय पर साइड-इफेक्ट्स की अनुमति है, जब तक कि आप गारंटी नहीं दे सकते कि एक निश्चित मॉड्यूल साइड-इफेक्ट्स उत्पन्न नहीं करता है। क्या एक मॉड्यूल "टाइप-सक्षम?"

मुझे लगता है कि एक प्रक्रियात्मक मैक्रो "शायद नहीं होना चाहिए" के दुष्प्रभाव होते हैं क्योंकि कुछ विवरण (नीचे देखें) पर भरोसा नहीं किया जा सकता है, लेकिन हमारे पास भाषा में टाइप-सिस्टम जैसी तंत्र नहीं होगा जो उन्हें पूरी तरह से मजबूर कर सके। कार्यात्मक।

इन विवरणों में अन्य प्रो मैक्रोज़ की तुलना में निष्पादन और समेकन का क्रम शामिल है, और क्या एक प्रो-मैक्रो को एक वृद्धिशील बिल्ड में फिर से निष्पादित किया जाता है। बाद के लिए हम बिल्ड स्क्रिप्ट में rerun-if-changed समान निर्भरता घोषित करने के लिए कुछ जोड़ना चाह सकते हैं। और बिल्ड स्क्रिप्ट की तरह ये घोषणाएं अधूरी या छोटी हो सकती हैं। हम सभी बग को स्थिर रूप से नहीं रोक सकते।

मुझे लगता है कि हमें साइड इफेक्ट्स के बारे में कुछ भी गारंटी देने से बचना चाहिए (यानी प्रो मैक्रो क्रेट को काम करने वाले साइड इफेक्ट्स पर भरोसा करने की अनुमति नहीं है, न ही उन्हें मॉड्यूल में कोड परिवर्तन के अलावा किसी अन्य चीज़ के लिए पुन: ट्रिगर होने पर भरोसा करने की अनुमति है जिसमें वे लागू होते हैं ( तो, कोई वैश्विक राज्य नहीं)।

हम बाद में इस आवश्यकता को फिर से चलाने-अगर-बदले और अन्य चीजों को निर्दिष्ट करने के तरीके से आराम कर सकते हैं।

(मेरे पास अर्ध-बेक्ड सामान्य बिल्ड स्क्रिप्ट/प्रो मैक्रो सुरक्षा प्रस्ताव है जो यहां कुछ हद तक मदद करेगा, लेकिन मैंने इसे अभी तक वास्तव में नहीं लिखा है)

आईएमओ प्रो मैक्रोज़/कस्टम व्युत्पन्न को किसी भी आई/ओ या बाहर के अन्य कनेक्शन के बिना सैंडबॉक्स वाले वातावरण में रखा जाना चाहिए और मिरी द्वारा मूल्यांकन किया जाना चाहिए, शायद क्रेनलिफ्ट जेआईटी के साथ।

@ est31 यह एक अच्छा विचार है लेकिन डीजल infer_schema जैसी चीजें! पहले से ही
मौजूद है, बाइंडजेन को फाइलों को पढ़ने और प्रोग्राम चलाने की जरूरत है, यहां तक ​​कि इसमें शामिल हैं! तथा
पर्यावरण आई/ओ का उपयोग करें।

9 नवंबर, 2017 06:19 पर, "est31" [email protected] लिखा है:

IMO प्रो मैक्रोज़ / कस्टम व्युत्पन्न को सैंडबॉक्स वाले वातावरण में रखा जाना चाहिए
बिना किसी I/O या बाहर के अन्य कनेक्शन के बिना और द्वारा मूल्यांकन किया जाएगा
मिरी, शायद एक क्रेनलिफ्ट जेआईटी के साथ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/38356#issuecomment-343124957 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3n5VOPdKBsu81Sp3tp2XlIQ05L865ks5s0t_PgaJpZM4LMWlc
.

ऐसा लगता है कि #40939 और #44528 पहले ही मर्ज हो चुके हैं... @jseyfried क्या आप चेकलिस्ट को अपडेट कर सकते हैं?

@ मार्क-आईएम अपडेट किया गया।

क्या प्रक्रियात्मक मैक्रोज़ प्रक्रियात्मक मैक्रोज़ उत्पन्न कर सकते हैं?

@VermillionAzure मैंने कोशिश नहीं की है, लेकिन मुझे कोई कारण नहीं दिख रहा है कि वे क्यों नहीं कर सके। यदि निश्चित रूप से, "रन-टाइम" कोड उत्पन्न करने वाले प्रो मैक्रोज़ की तरह, उन्हें उन क्रेटों से अलग होना चाहिए जहां उनका उपयोग किया जाता है।

syn में हम आज proc_macro::TokenNode की एक सीमा में भाग गए - ब्लॉक सीमांकक { ... } इनपुट टोकनस्ट्रीम में केवल एक स्पैन के साथ जुड़े हुए हैं इसलिए कोई ट्रिगर करने का कोई तरीका नहीं है त्रुटि जो केवल बंद होने की ओर इशारा करती है } । ऐसा लगता है कि Rustc में यह सीमा नहीं है।

mod m {
    type T =
}

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

एक प्रो मैक्रो में हम जो सबसे अच्छी चीजें कर सकते हैं, वे हैं ब्लॉक के अंदर अंतिम टोकन को इंगित करना, पूरे ब्लॉक को इंगित करना, या ब्लॉक के बाद अगले टोकन को इंगित करना, इनमें से कोई भी वास्तव में वह नहीं है जो आप ऊपर की तरह एक त्रुटि के लिए चाहते हैं।

एक सामान्य समाधान के लिए होगा Span::start और Span::end वापसी एक 1-चरित्र Span के बजाय एक LineColumn के रूप में वे वर्तमान में करते हैं, तो के लिए एक रास्ता बेनकाब Span से पहली पंक्ति/अवधि के स्तंभ पर जाएं।

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

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

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

@abonander का उल्लेख

स्पैन :: स्टार्ट और स्पैन :: एंड लाइन कॉलम के बजाय 1-कैरेक्टर स्पैन लौटाएं जैसा कि वे वर्तमान में करते हैं, फिर स्पैन से पहली पंक्ति/स्पैन के कॉलम तक जाने का एक तरीका बेनकाब करें।

इससे स्पैन उस विशेष व्यवहार को अपनाएगा जिसकी सीमांकित सूचियों की आवश्यकता है, लेकिन अन्य सभी स्पैन के लिए गलत होगा। आम तौर पर यह सही नहीं है। सामग्री में शामिल होने से foo(hi) जैसी अभिव्यक्ति के लिए अवधि प्राप्त करने पर विचार करें। अब आप foo को इंगित करना चाहते हैं और sp.begin() , लेकिन sp.begin() केवल foo के पहले वर्ण को इंगित करता है।

मुझे लगता है कि बेहतर समाधान दो स्पैन को proc_macro::TokenNode::Group जोड़ देंगे या मनमाने ढंग से स्पैन बनाने की अनुमति देंगे।

Span::begin / end रिटर्न प्रकारों को हालांकि बदलना पड़ सकता है: https://github.com/rust-lang/rust/pull/43604#issuecomment -327643229

मैं Span::def_site() प्राप्त करने का प्रयास कर रहा हूं ताकि मेरे प्रक्रियात्मक मैक्रो के दायरे में चीजों को हल किया जा सके। क्या मैं गलत समझ रहा हूं कि यह कैसे काम करना चाहिए?

लगभग वही कोड काम करता है यदि मैं Span::call_site() उपयोग करता हूं और MySend main.rs में परिभाषित किया गया है, जैसा कि मैं अपेक्षा करता हूं। हालांकि इसे 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`?

इसे सिन साइड पर ट्रैक करना: https://github.com/dtolnay/syn/issues/290।

@dtolnay
यहां मुद्दा यह है कि MySend को चरण 0 में आयात किया जाता है (अर्थात क्रॉस संकलन के दौरान होस्ट आर्किटेक्चर के लिए), इसलिए यह चरण 1 में उपलब्ध नहीं है (अर्थात लक्ष्य आर्किटेक्चर के लिए संकलन करते समय)।

यहां समाधान यह है कि प्रो-मैक्रो क्रेट को चरण 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 भेद को क्यों नहीं प्रभावित करता है? क्या यह जानबूझकर काम कर रहा है या दुर्घटना से?

• मेरे def_site() टोकन जैसे Send द्वारा उपयोग किए जा सकने वाले दायरे में और क्या है?

• यदि MySend को पुस्तकालय से आने की आवश्यकता है (जैसे कल्पना करें कि हम serde::Serialize प्राप्त कर रहे हैं) तो अंतिम उपयोगकर्ता को अभी भी अपने Cargo.toml में serde आवश्यकता है, भले ही हम न करें उन्हें extern crate serde लिखने की आवश्यकता है। इसे बनाने के लिए संभव हो जाएगा extern crate एक साथ def_site() प्रक्रियात्मक मैक्रो का Cargo.toml के खिलाफ अध्यक्ष संकल्प, और extern crate एक साथ call_site() बहाव के खिलाफ अध्यक्ष संकल्प कार्गो टीओएमएल?

बाहरी बक्से के लिए, मुझे लगता है कि क्रेट्स को प्रो मैक्रो द्वारा चरण 1 में स्पष्ट रूप से उपलब्ध कराने की आवश्यकता होगी।

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

@dtolnay

मेरी पिछली टिप्पणी में कोड में, यदि मैं MySend के बजाय भेजें के लिए एक impl उत्पन्न करने के लिए impl_mysend_for बदलता हूं तो सबकुछ संकलित होता है। यह किससेंड को हल कर रहा है और यह चरण 0 बनाम चरण 1 भेद को क्यों नहीं प्रभावित करता है? क्या यह जानबूझकर काम कर रहा है या दुर्घटना से?

अच्छा प्रश्न। अभी, परिभाषा स्थल पर प्रस्तावना दायरे में है (जब तक कि प्रो-मैक्रो क्रेट #![no_implicit_prelude] ) और यह एक दुर्घटना है (कुछ अर्थों में) चरण 0 बनाम चरण 1 भेद के कारण जैसा कि आप इंगित करते हैं .

हालांकि, एर्गोनॉमिक्स के लिए मुझे लगता है कि चरण 1 में प्रो-मैक्रो रूट पर निहित रूप से std होना चाहिए (ताकि आप हमेशा quote!(use std::...); ) और सुविधा/एर्गोनॉमिक्स के लिए प्रस्तावना कर सकें और चूंकि ये पहले से ही निहित हैं चरण 0 में। चरण 1 में जल्द ही रूट पर std जोड़ने के लिए एक पीआर होगा।

दायरे में और क्या है जिसका उपयोग मेरे def_site() टोकन द्वारा किया जा सकता है, जैसे भेजें?

जैसा कि ऊपर चर्चा की गई है, प्रस्तावना और (जल्द ही) std के अलावा, चरण 1 में दायरे में केवल अन्य चीजें स्वयं प्रो-मैक्रोज़ हैं (प्रो-मैक्रो फ़ंक्शंस नहीं , जो चरण 0 हैं)।

उदाहरण के लिए,

#[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() पहचान समाधान के साथ बाहरी क्रेट बनाना संभव होगा, और डाउनस्ट्रीम Cargo.toml के विरुद्ध call_site() पहचान समाधान के साथ बाहरी क्रेट बनाना संभव होगा?

हां, सिवाय मेरा मानना ​​है कि Span::def_site() साथ एक बाहरी टोकरा प्रक्रियात्मक मैक्रो के Cargo.toml के चरण 1 (लक्षित) निर्भरता के खिलाफ हल करना चाहिए - आज के चरण 0 निर्भरताएं होस्ट प्लेटफॉर्म के लिए संकलित पुस्तकालयों से जुड़ी हुई हैं . चूंकि चरण 1 निर्भरताएं अभी तक मौजूद नहीं हैं, बाहरी क्रेट का नाम अस्वच्छ रूप से हल हो जाता है, जो आपके द्वारा बताए गए अनुसार कष्टप्रद है।

एक बार जब हमारे पास चरण 1 निर्भरताएँ होती हैं, तो हमें शुरू करने के लिए प्रत्येक विस्तार में extern crate s उद्धृत करने की आवश्यकता नहीं होगी, इसलिए यह एक समस्या से कम होगा। हालांकि, हमें अभी भी इसे ठीक करना चाहिए - वर्तमान योजना पहले प्रो-मैक्रो क्रेट की लक्ष्य निर्भरताओं के खिलाफ हल करने का प्रयास करना है और फिर मंथन से बचने के लिए कम प्राथमिकता वाले चेतावनी चक्र के साथ अस्वच्छ समाधान पर वापस आना है।

बाहरी बक्से के लिए, मुझे लगता है कि क्रेट्स को प्रो मैक्रो द्वारा चरण 1 में स्पष्ट रूप से उपलब्ध कराने की आवश्यकता होगी।
#[proc_macro_derive(Serialize, attributes(serde), crates(serde))]

दिलचस्प है, हम इसे इस तरह लागू कर सकते हैं।

मैं इसके बजाय सोच रहा था कि चरण 1 क्रेट को प्रो-मैक्रो क्रेट रूट (उदाहरण के लिए #[phase(1)] extern crate foo; ) पर घोषित किया जाएगा ताकि यह सभी प्रो मैक्रोज़ (उदाहरण के लिए quote!(use foo::bar); ) में स्वचालित रूप से उपलब्ध हो। चूंकि extern crate वैसे भी बाहर आ रहा है, हम चरण 1 क्रेट को पूरी तरह से घोषित करने से बच सकते हैं - Cargo.toml से सभी लक्ष्य निर्भरताएं चरण 1 में proc-macro क्रेट रूट पर स्वचालित रूप से दायरे में होंगी।

मेरे कोड में मैंने पाया कि मैं दो उद्देश्यों के लिए स्पैन का उपयोग कर रहा हूं: नाम समाधान को नियंत्रित करने के लिए, और त्रुटि संदेशों को नियंत्रित करने के लिए। क्या ये दोनों अविभाज्य रूप से जुड़े हुए हैं, या क्या एक अवधि बनाना संभव होगा जो एक अलग अवधि के लाइन/कॉल त्रुटि संदेश स्थानों के साथ एक अवधि के नाम समाधान पहलू को मिश्रित करता है? मुझे उम्मीद है कि यह एक सामान्य आवश्यकता होगी।

अधिक विशिष्ट होने के लिए, मेरे पास मेरे कस्टम व्युत्पन्न के def_site के दायरे में लाया गया गुण है और मैं उपयोगकर्ता की संरचना के क्षेत्र में विशेषता विधियों का आह्वान करना चाहता हूं। यदि फ़ील्ड प्रकार सही विशेषता को लागू नहीं करता है, तो मैं चाहता हूं कि त्रुटि संदेश संबंधित स्ट्रक्चर फ़ील्ड को रेखांकित करे।

मैं def_site अवधि के साथ विधि कॉल उत्पन्न कर सकता हूं जो संकलित और चलता है लेकिन त्रुटि संदेश हमेशा व्युत्पन्न विशेषता को इंगित करते हैं जैसे हमने मैक्रोज़ 1.1 के साथ देखा था।

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

या मैं स्ट्रक्चर फ़ील्ड की पहचान या प्रकार के समान अवधि के साथ विधि कॉल उत्पन्न कर सकता हूं, जो सही रेखांकन दिखाता है लेकिन मेरे def_site पर दायरे में विशेषता को हल करने में विफल रहता है।

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

मैं सही तरीके से कैसे हल कर सकता हूं और त्रुटियों को अपनी इच्छानुसार कैसे दिखा सकता हूं?

@dtolnay यह एक उत्कृष्ट बिंदु है, धन्यवाद।

मुझे लगता है कि https://github.com/rust-lang/rust/issues/46489 को ठीक करने का उचित तरीका इसे बनाना हो सकता है ताकि जेनरेट किए गए #[derive(…)] टोकन में नाम-रिज़ॉल्यूशन-स्पैन हो स्कोप टाइप डेफिनिशन के रूप में, और त्रुटि-संदेश-स्पैन quote! {} मैक्रो इनवोकेशन पर जिसने उन्हें बनाया।

वर्तमान में स्वच्छता के साथ क्या कहानी है? मेरे पास प्रक्रियात्मक मैक्रो की तरह कार्य है जो काम करता था (4 महीने पहले) लेकिन जंग 1.24.0-रात (बी 65f0bedd 2018-01-01) के रूप में यह शिकायत करता है कि तर्क दायरे में नहीं पाया जा सकता है।

क्षमा करें, पहले समस्या ट्रैकर की खोज करनी चाहिए थी, ऐसा लगता है कि मैंने अभी-अभी https://github.com/rust-lang/rust/issues/46489 मारा है

मैंने #47311 दायर किया जो मेरा मानना ​​​​है कि वर्तमान में व्युत्पन्न (Deserialize) के सही कार्यान्वयन को रोकता है। प्रक्रियात्मक मैक्रोज़ एक ऐसी संरचना का निर्माण नहीं कर सकते हैं जिसमें निजी क्षेत्र हों।

दायर एक और, # 47,312 जो की तरह एक अनाम टपल struct क्षेत्र के लिए उपयोग में self.0 के अंतराल पर विभिन्न आवश्यकताओं है . की तरह एक नाम दिया struct क्षेत्र के लिए उपयोग की तुलना में टोकन self.x .

47311 और #47312 क्रमशः #48082 और #48083 में तय हैं।

मेरे पास उपरोक्त दो पीआर समीक्षा/टिप्पणी की प्रतीक्षा कर रहे हैं।

ऐसा लगता है कि https://github.com/rust-lang/rust/pull/41029 अब हो गया है?

उस पीआर को छोड़ दिया गया लेकिन पुनर्जीवित किया गया और # 48465 में काम करना जारी रखा। फिलहाल क्रेटर का इंतजार है।

@petrochenkov @nrc

syntax::ext::expand , ऐसा प्रतीत होता है कि proc_macro_attribute s वर्तमान में कई संदर्भों (गैर-संपूर्ण) में संसाधित नहीं किए जा रहे हैं:

• ब्लॉक पर ( fold_block() एक नोप है)
• बयानों/अभिव्यक्तियों पर (#41475, #43988)
• extern {} ब्लॉक के अंदर (#48747)

RFC 1566 विशिष्ट AST नोड प्रकारों को सूचीबद्ध नहीं करता है, जिन पर मैक्रोज़ को लागू किया जा सकता है, यह सुझाव देते हुए कि उन्हें किसी भी चीज़ पर लागू होना चाहिए। लेकिन यह थोड़ा हास्यास्पद हो सकता है इसलिए हमें स्पष्ट रूप से यह स्थापित करना चाहिए कि क्या संसाधित करने की आवश्यकता है लेकिन नहीं हैं, और जहां विशेषताओं की अनुमति कभी नहीं दी जानी चाहिए लेकिन वर्तमान में हो सकती है (#43988)

@abonander इरादा यह है कि

@nrc कहीं भी है जो उन स्थानों की गणना करता है क्योंकि संदर्भ केवल यह कहता है कि विशेषताएँ किसी भी आइटम पर लागू की जा सकती हैं। हालाँकि, मुझे पूरा यकीन है कि लिंट विशेषताओं को ब्लॉक और स्टेटमेंट पर भी लागू किया जा सकता है।

@nrc कहीं भी है जो उन स्थानों की गणना करता है क्योंकि संदर्भ केवल यह कहता है कि विशेषताओं को किसी भी आइटम पर लागू किया जा सकता है। हालाँकि, मुझे पूरा यकीन है कि लिंट विशेषताओं को ब्लॉक और स्टेटमेंट पर भी लागू किया जा सकता है।

afaik नहीं है - किसी भी अभिव्यक्ति पर विशेषताओं के लिए एक स्वीकृत आरएफसी और एक अस्थिर फीचर ध्वज है, लेकिन मुझे लगता है कि हमने केवल बयान और ब्लॉक पर स्थिर किया है। संदर्भ डेटा से बाहर है।

यह मुद्दा:

स्थिरता जांच (खरीद-) मैक्रोज़ (मुद्दा #34079)।

अब WRT proc-macros बंद हो गया है। मेरे पीआर ने मैक्रोज़ 2.0 मैक्रोज़ के लिए स्थिरता-जांच को नहीं जोड़ा, यही वजह है कि यह मुद्दा अभी भी खुला है (हालाँकि इसके बजाय शायद यह एक नया मुद्दा होना चाहिए)।

@rfcbot fcp मर्ज

मैं रस्ट 1.28 रिलीज के लिए मैक्रोज़ 2.0 कहानी के एक सबसेट को मैक्रोज़ 1.2 के रूप में स्थिर करने का प्रस्ताव देना चाहता हूं। रस्ट 1.28 10 मई, 2018 को रात में प्रवेश करता है (इस लेखन से ~2.5 सप्ताह) और 2 अगस्त, 2018 को स्थिर हो जाएगा। मुझे लगता है कि FCP 10 मई के कटऑफ से पहले 1.27 बीटा में प्रवेश कर सकता है, लेकिन मैं इसे रोकना चाहता हूं उस कटऑफ के होने तक यहां किसी भी स्थिरीकरण को बंद करें और इसे 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] @किमुंडी
• [ ] @SimonSapin
• [एक्स] @ एलेक्सक्रिचटन
• [x] @ एट्यूरॉन
• [एक्स] @ क्रैमर्टज
• [x] @dtolnay
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [एक्स] @ एनआरसी
• [ ] @pkfelix
• [x] @scottmcm
• [x] @sfackler
• [x] @ नावों के बिना

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

एक बार जब अधिकांश समीक्षकों ने स्वीकृति दे दी (और कोई आपत्ति नहीं), तो यह अपनी अंतिम टिप्पणी अवधि में प्रवेश करेगा। यदि आपको कोई बड़ा मुद्दा मिलता है जिसे इस प्रक्रिया में किसी भी बिंदु पर नहीं उठाया गया है, तो कृपया बोलें!

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए

cc @ rust-lang/compiler, आप सभी मुझे पता है कि इसमें भी बहुत रुचि है और कृपया कोई आपत्ति उठाने के लिए स्वतंत्र महसूस करें। यदि आपको कोई अवरोधन आपत्ति है तो मैं इसे आपके लिए भी पंजीकृत कर सकता हूँ

ऐसा लगता है, स्थिरीकरण के लिए प्रस्तावित एपीआई का उपयोग करके, प्रो मैक्रो आसानी से सभी प्रकार के टोकन उत्पन्न कर सकते हैं, या उन्हें इनपुट से आउटपुट में कॉपी कर सकते हैं, लेकिन एक सतही स्तर पर भी टोकन की एक धारा का आसानी से निरीक्षण नहीं कर सकते हैं। उदाहरण के लिए, Literal Eq या PartialEq लागू नहीं करता है। इसकी कोई खास वजह? (और यहां तक ​​​​कि यह केवल एक मूल्य निकालने और इसे कोड में संसाधित करने के बजाय निर्दिष्ट स्थिर मानों के साथ तुलना करने की अनुमति देगा।)

एक प्रो मैक्रो कार्यान्वयन के अंदर, TokenStream , एक प्रो मैक्रो एक शाब्दिक आत्मनिरीक्षण के लिए क्या कर सकता है? या, उस बात के लिए, एक का मान निकालें? क्या यह अभी तक समर्थित नहीं है? क्या भविष्य में इसका समर्थन करने की कोई योजना है?

(मैं प्रस्तावित उपसमुच्चय के स्थिरीकरण को अवरुद्ध करने का प्रयास नहीं कर रहा हूं; मैं बस उस उपसमुच्चय और उसकी इच्छित विशेषताओं को बेहतर ढंग से समझना चाहता हूं।)

@alexcrichton नई वस्तुओं में
हाइजीनिक न हो। एएसटी में जोड़े गए नए आइटम उसी नाम स्थान में प्रवेश करेंगे जैसे
मॉड्यूल में अन्य आइटम।

मैं रस्ट कोर टीम में नहीं हूं, और मैंने पिछली सभी चर्चाओं को अच्छी तरह से नहीं देखा है, लेकिन यह मुझे बहुत बुरा लगता है। क्या होगा यदि मैक्रो सहायक आइटम उत्पन्न करना चाहता है जिसे केवल मैक्रो द्वारा ही एक्सेस किया जा सकता है?

स्वच्छता को खत्म करने के बजाय, मुझे लगता है कि पूर्ण 100% स्वच्छता को लागू करना बेहतर है, लेकिन मैक्रोज़ को किसी विशेष चर के लिए स्वच्छता से स्पष्ट रूप से ऑप्ट-आउट करने का एक तरीका प्रदान करें।

@joshtriplett आप लिटरल के लिए डिस्प्ले

@joshtriplett हाँ जैसा कि @dtolnay ने उल्लेख किया है कि आप Display जो कि एक टोकरा है जैसे कि लिटरलटेक्स्ट बनाया गया है। आम तौर पर एपीआई का इरादा "न्यूनतम" होना है, न कि प्रथम श्रेणी एपीआई जिसमें सभी घंटियां और सीटी हैं। वे शायद बाद में आएंगे!

स्थिरीकरण का यह दौर इस अर्थ में "अधिकतम न्यूनतम" होने का इरादा है कि यह सभी उपयोग मामलों को कवर करने के लिए कम से कम कार्यक्षमता प्रदान करता है (उर्फ Display Literal और इसकी व्याख्या करने के लिए और कुछ नहीं )

@Pauan यह बहुत अच्छा नहीं है, हाँ, लेकिन यह ठीक वैसा ही है जैसे macro_rules! जो अब वर्षों से स्थिर है और कई अलग-अलग संदर्भों में काम कर रहा है। हम यहां हाइजीन और बेहतर इलाज को सक्षम बनाना चाहते हैं लेकिन हम अभी पूरी तरह तैयार नहीं हैं। Span::call_site() कंस्ट्रक्टर यहां लिंचपिन है जहां इसका उपयोग करके आप "कोई स्वच्छता नहीं" का अनुरोध कर रहे हैं। अंतत: हम और विकल्पों को स्थिर करेंगे।

दुर्भाग्य से "पूर्ण 100% स्वच्छता" वर्षों दूर है, और इस प्रस्ताव का उद्देश्य जंग 2018 के लिए कुछ स्थिर प्राप्त करना है

@alexcrichton तो क्या अब इसे एक स्वच्छता छेद के साथ स्थिर करने की योजना है और फिर कुछ युग/युग/संस्करण बाद में उस स्वच्छता छेद को ठीक करते हैं?

चूंकि Span::call_site() मौजूद है, तो क्या कोई कारण है कि अभी इसमें पूर्ण स्वच्छता नहीं हो सकती है? क्या यह जनशक्ति/समय की कमी है, या क्या सैद्धांतिक/अर्थपूर्ण चिंताएं हैं जिन्हें अभी भी आरएफसी में दूर करने की आवश्यकता है?

@Pauan दोहराने के लिए इस अर्थ में कोई वास्तविक "छेद" नहीं है कि यह आज पहले से मौजूद है। macro_rules! और कस्टम व्युत्पन्न के साथ यह ठीक वैसी ही स्वच्छता कहानी है। यह प्रस्ताव प्रभावी रूप से उसी का एक विस्तार है, कुछ नया पेश नहीं कर रहा है।

एक "पूर्ण स्वच्छता कहानी" को देखते हुए हम हमेशा किसी न किसी रूप में ऑप्ट-आउट करना चाहेंगे। वर्तमान में वह ऑप्ट-आउट Span::call_site() (प्रभावी रूप से) है। केवल यह स्थिर करके कि हम केवल स्वच्छता के लिए ऑप्ट-आउट तंत्र को स्थिर कर रहे हैं। अंततः हम जहां आवश्यक हो, वस्तुओं को पूरी तरह से स्वच्छ बनाने के लिए और अधिक कार्यक्षमता को स्थिर करेंगे।

स्वच्छता को स्थिर करना बहुत दूर है। (AFAIK) अनसुलझे शोध प्रश्न हैं, यह जनशक्ति का सवाल नहीं है।

@dtolnay आह, मैं देखता हूँ। तो, आप टेक्स्ट जेनरेट करते हैं और फिर टेक्स्ट को दोबारा पार्स करते हैं? मुझे लगता है कि यह फिलहाल काम करता है।

cc @ rust-lang/compiler, आप सभी मुझे पता है कि इसमें भी बहुत रुचि है और कृपया कोई आपत्ति उठाने के लिए स्वतंत्र महसूस करें। यदि आपको कोई अवरोधन आपत्ति है तो मैं इसे आपके लिए भी पंजीकृत कर सकता हूँ

मेरे पास अभी भी समीक्षा करने के लिए कुछ चीजें हैं और युगल प्रो-मैक्रो एपीआई के साथ एक पीआर प्रगति पर है।

यह मैक्रो_रूल्स के साथ ठीक वैसी ही स्वच्छता की कहानी है! और कस्टम व्युत्पन्न।

ज़रूर, लेकिन मैंने सोचा था कि लक्ष्यों में से एक बेहतर मैक्रो सिस्टम बनाना था, इसलिए मौजूदा (टूटी हुई और सीमित) प्रणाली की ओर इशारा करना मेरे लिए बहुत आश्वस्त नहीं है।

एक "पूर्ण स्वच्छता कहानी" को देखते हुए हम हमेशा किसी न किसी रूप में ऑप्ट-आउट करना चाहेंगे।

बिल्कुल, लेकिन मेरा कहना यह है कि चूंकि स्वच्छता को तोड़ने के लिए Span::call_site() का उपयोग करना संभव है (और इस प्रकार macro_rules! कार्यक्षमता प्राप्त करें) यदि वांछित है, तो इसे डिफ़ॉल्ट रूप से स्वच्छ बनाकर आप स्वच्छता और दोनों तक पहुंच प्राप्त करते हैं। गैर-स्वच्छता। जबकि अगर यह गैर-स्वच्छता से स्थिर हो जाता है तो यह केवल गैर-स्वच्छता के साथ फंस जाता है।

अंततः हम जहां आवश्यक हो, वस्तुओं को पूरी तरह से स्वच्छ बनाने के लिए और अधिक कार्यक्षमता को स्थिर करेंगे।

यह काफी कष्टप्रद (और भ्रमित करने वाला) बैंड-सहायता की तरह लगता है: प्रोक मैक्रोज़ अधिकांश स्थितियों (लेकिन आइटम नहीं) में हाइजीनिक होगा, लेकिन फिर आप आइटम के लिए स्वच्छता में ऑप्ट-इन करने के लिए एक नई सुविधा का उपयोग कर सकते हैं। क्या मैं यह सही समझ रहा हूँ?

(AFAIK) अनसुलझे शोध प्रश्न हैं, यह जनशक्ति का सवाल नहीं है।

ठीक है, यह काफी उचित है। मैं समीचीनता और व्यावहारिकता की इच्छा को समझता हूं। जब तक योजना अंततः एक बाद युग / युग / संस्करण में डिफ़ॉल्ट रूप से ठोस स्वच्छता है के रूप में, तो मैं अस्थायी रूप से ख़राब स्वच्छता होने के साथ ठीक हूँ। मैं बस यह नहीं चाहता कि हम कुछ ऐसा स्थिर करें जिसके लिए हमें बाद में पछताना पड़े।

एक मायने में, यह पहले से ही "डिफ़ॉल्ट रूप से स्वच्छ है," यह सिर्फ इतना है कि डिफ़ॉल्ट अभी तक समर्थित नहीं है। Span::call_site ऑप्ट आउट है। :)

@Pauan @alexcrichton ने जो कहा, बताने के लिए:

पहचानकर्ता बनाने के लिए Span आवश्यकता होती है, जिसमें स्वच्छता संबंधी जानकारी होती है। (देखें Term::new )

भविष्य में, हम Span s के निर्माण के कई अलग-अलग तरीकों का खुलासा कर सकते हैं, जो स्वच्छता के विभिन्न विकल्पों को दर्शाते हैं। लेकिन अभी के लिए, हम केवल Span::call_site पर्दाफाश करेंगे जो कॉलर का दायरा लेता है।

इस तरह, हम बाद में स्वच्छता जोड़ने की क्षमता को खुला रखते हुए पूरी स्वच्छता प्रणाली को तुरंत स्थिर करने से बच सकते हैं। मुझे लगता है कि इस मुद्दे को हल करने के लिए यह एक बहुत ही चतुर चाल है!

@rpjohnst तो आपका मतलब है कि एक Span::call_site ?

यदि ऐसा है, तो यह सही लगता है: उस स्थिति में भविष्य में स्वच्छता को वास्तव में स्वच्छ और पीछे की ओर संगत तरीके से जोड़ा जा सकता है।

@lफेयरी आह, मैं देखता हूं, मुझे एहसास नहीं हुआ था कि Span::call_site का उपयोग करना जरूरी था, मैंने सोचा कि एक अंतर्निहित डिफ़ॉल्ट अस्पष्ट दायरा था। विस्तार से बताने के लिए धन्यवाद! आप सही कह रहे हैं कि यह एक बहुत ही चतुर चाल है।

ऐसे में मुझे अब कोई आपत्ति नहीं है।

@एलेक्सक्रिचटन

गुण, macro_rules, और प्रक्रियात्मक
मैक्रोज़ सभी मारो नेमस्पेस में रहते हैं।

पिछली बार मैंने #[feature(proc_macro)] साथ जाँच की, इसमें व्युत्पन्न-त्रुटि-श्रृंखला क्रेट के लिए स्थिर कोड में एक पिछड़ा-असंगत परिवर्तन था जैसा कि यहां वर्णित

@ अर्नवियन ओह प्रिय, यह बुरा लगता है! हम वास्तव में कोई बड़ा पिछड़ा-असंगत परिवर्तन नहीं कर सकते हैं, इसलिए हमें इसे काम करते रहने के लिए एक तरीका निकालना होगा। #[derive] विस्तार के बाद तक "यह एक विशेषता नहीं है" त्रुटियों को स्थगित करना एक संभावित समाधान होगा।

ऐसा प्रतीत होता है कि #48644 और #47786 हो चुके हैं। क्या कोई ओपी अपडेट कर सकता है?

@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 impls का एक गुच्छा भी हो सकता है।

@abonander इस पर चर्चा की गई है, लेकिन निष्कर्ष उन्हें स्थिरीकरण के पहले पास के लिए आवश्यक बनाने के बजाय बाद में जोड़ना है। उन्हें Display कार्यान्वयन के साथ crates.io पर बनाया जा सकता है और हमारे पास भविष्य में बाद में जोड़ने के लिए जगह है

:घंटी: उपरोक्त समीक्षा के अनुसार, यह अब अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । घंटी:

@एलेक्सक्रिचटन
!Send और !Sync proc मैक्रो एपीआई प्रकारों के लिए निहितार्थ स्पष्ट रूप से नहीं लिखे गए हैं, लेकिन अनुमानित हैं।
कुछ स्ट्रक्चर्स (जैसे Op ) के लिए अनुमानित इम्प्लांट https://github.com/rust-lang/rust/issues/38356#issuecomment -383693017 में निर्दिष्ट से भिन्न है।
इम्प्लांट्स को स्पष्ट रूप से जोड़ना शायद समझ में आता है।

उफ़ हाँ सच में! मैंने इसे संबोधित करने के लिए 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 s देता है, जो कि यदि Term::as_str सफल होता है, आंतरिक दायरे से सख्ती से छोटा होता है।
सामान्य तौर पर, जिस तरह से proc_macro विस्तार होता है, और क्योंकि Term थ्रेड-लोकल है, Term बचने के बहुत कम तरीके हैं Term , और मुझे लगता है कि thread_local! प्रभावी रूप से एकमात्र था।

लेकिन Box::leak भी मौजूद है! यह अभी भी अस्थिर है, लेकिन आज, Box::leak(Box::new(term)).as_str() &'static str लौटाता है। मुझे आश्चर्य है कि क्या Box::leak (cc @RalfJung) द्वारा तोड़े गए अन्य सार तत्व हैं

OTOH, यह केवल इसलिए जटिल है क्योंकि Term स्ट्रिंग डेटा का स्वामी नहीं हो सकता, क्योंकि यह Copy ।
अगर हम 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 फीचर गेट लागू होगा? कमिट 79630d4fdfc775b241cae0a209edec2687a29f0f को अब इसकी आवश्यकता है, लेकिन quote! अभी भी #[unstable(feature = "proc_macro" ... रूप में चिह्नित है।
3. क्या proc_macro_path_invoc , proc_macro_mod , proc_macro_expr , और proc_macro_non_items के स्थिरीकरण के लिए ट्रैकिंग समस्याएं दर्ज की जाएंगी?

_{असंबंधित पक्ष प्रश्न: quote! कहाँ लागू किया गया है?}

@mjbshaw Sooo मज़ा कहानी: यह में कार्यान्वित किया जाता proc_macro::quote ।
rustc_metadata दिखावा किसी भी टोकरा नामित कि proc_macro नाम के एक प्रक्रियात्मक मैक्रो शामिल quote उस में है, लेकिन इस्तेमाल किया कार्यान्वयन से है proc_macro rustc_metadata के खिलाफ लिंक।

मेरे पास अभी भी समीक्षा करने के लिए कुछ चीजें हैं और युगल प्रो-मैक्रो एपीआई के साथ एक पीआर प्रगति पर है।

पीआर की समीक्षा करें: https://github.com/rust-lang/rust/pull/50473

1.2 API के लिए फ़ीचर अनुरोध: कोण कोष्ठक ( < / > ) के लिए एक सीमांकक जोड़ें ताकि <T> ( fn foo<T>() {} ) जैसी चीज़ों को इस रूप में पार्स किया जाएगा एक Group । ऐसा नहीं करने से पार्सिंग हो जाती है जैसे जेनरिक अनावश्यक रूप से जटिल।

@mjbshaw मुझे नहीं लगता कि यह निर्धारित करने के लिए टोकन स्तर पर काम करेगा कि क्या दो < > एक दूसरे के साथ समूहीकृत हैं। उदाहरण के लिए निम्नलिखित मैक्रो इनपुट में:

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

हो सकता है कि यह दो बूलियन एक्सप्रेशन हैं $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>);

मैंने ओपी को थोड़ा अपडेट किया है, लेकिन हमारे पास स्वच्छता से संबंधित दो संभावित शोस्टॉपर बग की तरह मुझे क्या दिखता है, इस पर निर्भर करता है कि वे कैसे निकलते हैं:

• स्वच्छता अजीब है
• स्वच्छता अजीब है

इस थ्रेड का अनुसरण करने वालों के लिए एपीआई को मूल FCP टिप्पणी से https://github.com/rust-lang/rust/pull/50473 में @petrochenkov द्वारा प्रस्तावित किए जाने की संभावना है। अब तक का सारांश है:

• Term::new का नाम बदलकर Term::ident और इनपुट की पुष्टि करें
• Term::lifetime और इनपुट की पुष्टि करें
• Term::raw_ident और इनपुट मान्य करें
• Op का नाम बदलकर Punct
• Punct::new पर इनपुट मान्य करें
• Op::op का नाम बदलकर Punct::as_char

एक छोटा एपीआई अनुरोध जो मैं करूंगा (संभवतः #50473 - @petrochenkov में) टोकन को टोकनस्ट्रीम पर जोड़ने का कोई तरीका है। संभवतः:

impl Extend<TokenTree> for TokenStream

मेरा मानना ​​है कि इससे quote::Tokens प्रकार (जो मूल रूप से Vec<TokenTree> ) को खत्म करना संभव होगा और पारिस्थितिकी तंत्र में विभिन्न प्रकारों के प्रसार को कम करना संभव होगा, जिसका अर्थ है "कुछ टोकन" - https में ट्रैक किया गया

@ dtolnay के उपरोक्त सुझाव पर +1।

उपरोक्त समीक्षा के अनुसार, विलय के स्वभाव के साथ अंतिम टिप्पणी अवधि अब पूरी हो गई है ।

मेरे दो प्रश्न हैं:

1. जैसा कि पहले ही यहां पूछा गया quote! के बारे में क्या है? अंतिम TokenStream बनाने का डिफ़ॉल्ट तरीका क्या होना चाहिए? क्या इसे मैन्युअल रूप से किया जाना चाहिए? या किसी को quote टोकरा का उपयोग करना चाहिए? क्या proc_macro::quote! को भविष्य में किसी बिंदु पर स्थिर किया जाना चाहिए?

2. क्या मेरी समझ में यह सही है कि फ़ंक्शन-जैसे मैक्रो और विशेषता-जैसी मैक्रो घोषित करने के बीच का अंतर केवल तर्कों की संख्या है? अर्थात:

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

   अंतर केवल इतना है कि एक तर्क के रूप में एक TokenStream लेता है, जबकि दूसरा दो लेता है। क्या यह थोड़ा सूक्ष्म नहीं है? इसके बजाय #[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 टोकरा यहां प्रस्तावित एपीआई पर बनाता है। साथ ही @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 कार्यान्वयन के समान) प्राप्त कर सकते हैं? ऐसा लगता है कि इसे जोड़ना काफी सुरक्षित होना चाहिए। मुझे पीआर लिखने में खुशी हो रही है, लेकिन मैं नहीं चाहता कि यह विचार ना हो।

@mjbshaw क्या PartialEq<Punct> भी स्पैन की तुलना करेगा? PartialEq<char> ठीक लगता है, ओटीओएच।

@eddyb PartialEq Ident लिए स्पैन की तुलना नहीं करता है (मुझे पता है कि यह proc-macro2 स्रोत है न कि proc-macro स्रोत)। मैं इस बात को लेकर दुविधा में हूं कि क्या स्पैन को तुलना में शामिल किया गया है, लेकिन मैं इस संबंध में समान व्यवहार करने के लिए Punct और Ident अपेक्षा करता हूं। Punct भी अपना Spacing , जो मुझे लगता है कि तुलना में शामिल किया जाएगा (हालांकि शायद अन्य अलग तरह से सोचते हैं)।

मैं अभी के लिए केवल PartialEq<char> को Punct लिए लागू करने के लिए ठीक हूं। PartialEq<Punct> को बाद में हैश आउट किया जा सकता है।

@mjbshaw proc-macro2 क्रेट को बिल्कुल वैसा नहीं होने की स्वतंत्रता proc_macro अपस्ट्रीम है और हमें विभिन्न ट्वीक्स के साथ प्रयोग करने की कुछ स्वतंत्रता देता है। मुझे संदेह है कि अगर यह crates.io पर अच्छी तरह से काम करता है तो हम इसे proc_macro जोड़ सकते हैं, लेकिन यह निश्चित रूप से पीछे की ओर है- proc_macro जोड़ने के लिए संगत है इसलिए हम नंगे न्यूनतम से शुरू कर रहे हैं और एक बार स्थिर होने पर हम वहां से आगे बढ़ सकते हैं।

मैंने मैक्रोज़ 1.2 से संबंधित सभी बग्स के लिए कुछ https://github.com/rust-lang/rust/issues/50050 है , जिसका @petrochenkov के पास समाधान है ।

गनोम-क्लास proc_macro2/syn/quote में परिवर्तन के साथ टूट गया, साथ ही proc मैक्रो से मॉड्यूल बनाने के लिए फीचर गेट। यह अब तय हो गया है, सौभाग्य से।

इस छोटे से पारिस्थितिकी तंत्र में बदलावों को शीर्ष पर रखने के लिए मुझे किन चीजों की निगरानी करनी चाहिए?

@federicomenaquintero यदि आप अस्थिर सुविधाओं का उपयोग करते हैं, तो नियमित सीआई नौकरी (दैनिक, साप्ताहिक, जो भी आपके लिए काम करता है) पर विचार करें जो आपके कोड को नवीनतम नाइटली के साथ संकलित करता है और विफल होने पर आपको सूचित करता है। (ट्रैविस-सीआई अपनी सेटिंग में इस तरह के "क्रॉन जॉब" को सक्षम करने का समर्थन करता है।)

@SimonSapin धन्यवाद, यह एक अच्छा विचार है। हम उन क्रेटों के संस्करणों को अपने Cargo.toml में पिन करते हैं, लेकिन हो सकता है कि यह संस्करण संख्याओं को हटाने का समय हो और कार्गो को नवीनतम डाउनलोड करने दें। क्या यह करने का यह सही तरीका है?

@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 दोनों सुविधाओं की आवश्यकता है लेकिन एक ही समय में उपयोग नहीं किया जा सकता है। जैसा कि मैं समझता हूं कि प्रो मैक्रोज़ का स्थिरीकरण फीचर फ़्लैग की आवश्यकता को समाप्त कर देगा?

दूसरी बात यह है कि इस तरह #[my_attribute] संभावित रूप से कोड उत्पन्न कर सकता है जो #[other_attribute] को कभी भी चलने से रोकता है। वास्तव में क्या अच्छा होगा यदि "बाहरी" विशेषता पर, मैं आंतरिक विशेषताओं को पंजीकृत कर सकता हूं जो उसी तरह काम करते हैं जैसे #[derive(Foo)] काम करते हैं।

डमी सत्र के बारे में

क्या इस घबराहट को एक डमी "सत्र" बनाने के साथ प्रतिस्थापित करना संभव/वांछनीय होगा? या शायद एक बनाने के लिए एक सार्वजनिक एपीआई (स्थिरीकरण के पथ के साथ) जोड़ें?

मुझे लगता है कि डमी सत्र करना बहुत उपयोगी होगा। proc-macro बक्से के लिए इकाई परीक्षण लिखना बहुत असंभव है या कम से कम बहुत असुविधाजनक है। इसके अलावा, यह न केवल TokenStream::from_str , बल्कि एक सत्र की आवश्यकता वाले अन्य कार्य भी हैं।

@एलेक्सक्रिचटन

मैंने मैक्रोज़ 1.2 से संबंधित सभी बग्स के लिए कुछ ट्राइएज कार्य किया है। अधिकांश बग को "गंभीर बग" या "सभी अवधि से संबंधित बग" में वर्गीकृत किया जा सकता है।

मैं https://github.com/rust-lang/rust/issues/50504 को "गंभीर" स्थिति में अपग्रेड करना चाहता हूं - वर्णित मॉड्यूल समस्या केवल एक गहरी समस्या का एक लक्षण है - प्रो मैक्रोज़ के लिए विस्तार आईडी नहीं ठीक से दर्ज किया जा रहा है। मुझे नहीं पता कि इसके और क्या परिणाम हो सकते हैं।
अंतर्निहित समस्या को ठीक करने वाला एक पीआर है (https://github.com/rust-lang/rust/pull/51952), लेकिन फिक्स से प्रतिगमन हैं और मैंने अभी तक उनके माध्यम से नहीं देखा है।

मैंने 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 भी शामिल करता हूं।

मुझे यह बहुत आश्चर्यजनक लगता है, क्योंकि मेरा प्रोजेक्ट एक विशिष्ट रस्ट नाइटली संस्करण (रस्टसी 1.29.0-नाइटली (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 मुझे नहीं लगता कि यहाँ समस्या है। मुझे लगता है कि @realcr पहले ही proc-macro2 अपडेट कर चुका है क्योंकि त्रुटि संदेश हर जगह proc-macro2-0.4.8 कहता है। समस्या यह है कि रात का संस्करण एक के लिए तय किया गया है जिसमें # 52081 शामिल नहीं है। मुझे आज भी यही समस्या थी और मैं सोच रहा था कि क्यों proc-macro2 केवल मामूली संस्करण को टक्कर दी। लेकिन मैं इस बात से बहुत परिचित नहीं हूं कि proc-macro2 संगतता को कैसे संभालता है।

@realcr अपने रात्रिकालीन कंपाइलर को अपडेट करने का प्रयास करें या अपने प्रोजेक्ट में proc-macro-2 संस्करण < 0.4.8 करें।

@alexcrichton , @LukasKalbertodt : त्वरित उत्तर के लिए धन्यवाद।
मैंने अभी-अभी अपने रात्रिकालीन संकलक को नवीनतम संस्करण में अद्यतन किया है। इसने प्रो-मैक्रो -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 : अगर आपको लगता है कि यह प्रासंगिक नहीं है तो कुछ भी संपादित करने या हटाने के लिए स्वतंत्र महसूस करें। मैं आपकी मदद करने की पूरी कोशिश करता हूं, मेरे लिए यह जानना मुश्किल है कि विषय पर क्या है और क्या नहीं। त्रुटि संदेश "(समस्या # 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 जो प्रक्रियात्मक मैक्रो या कंपाइलर में एक बग हो सकता है, क्या आप उसके लिए एक समर्पित मुद्दा दर्ज कर सकते हैं?

ठीक है, मुझे लगता है कि कम से कम काम करने वाला दिखने के लिए मुझे पहले अपना कोड फिर से लिखना चाहिए :) अभी ऐसा नहीं है, आप लोगों ने इस सुविधा के साथ बहुत कुछ बदल दिया है। बीआरबी जब किया। अगर यह गायब नहीं होता है तो मैं एक समस्या पैदा करता हूं।

@एलेक्सक्रिचटन
क्या आप जानते हैं कि प्रक्रियात्मक मैक्रो को पारित करने से पहले टोकन पर "प्रीप्रोसेसिंग" क्या लागू होता है?
मुझे पता है कि व्युत्पन्न कम से कम $crate समाप्त हो गया है और इनपुट टोकन प्राप्त करने से पहले cfg विस्तार किया गया है (साथ ही स्ट्रिंग्स के माध्यम से राउंडट्रिप्स पूरी तरह से दोषरहित नहीं हैं, लेकिन यह ठीक करने योग्य है)।

हमें यह सुनिश्चित करना चाहिए कि इनमें से कोई भी नए स्थिर प्रक्रियात्मक मैक्रोज़ के साथ न हो और उन्हें इनपुट टोकन ठीक से मिलें (मॉड्यूलो बग)।

@alexcrichton क्षमा करें, cargo expand किसी कारण से इस टोकरे पर काम नहीं करता है। पुष्टि नहीं कर सकता कि समस्या मेरी तरफ है या कंपाइलर पर है। इसलिए मैं खुद को दोष देना जारी रखूंगा जब तक कि इस संभावना को पूरी तरह से बाहर नहीं किया जाता है।

@petrochenkov proc-macros का विस्तार आज तक बहुत अच्छी तरह से किया गया है, इसलिए मैं नाम संकल्प टुकड़ों की तुलना में इसके बारे में बहुत कम चिंतित हूं। मैं व्यक्तिगत रूप से प्रीप्रोसेसिंग से अवगत नहीं हूं, लेकिन मुझे पता है कि एक विस्तार आदेश है जहां अंतिम रन प्राप्त होता है, सीएफजीएस पहले चलता है, और अन्यथा यह अधिकतर पुनरावृत्त होता है।

हालांकि मैं सहमत हूं कि इसके लिए ऑडिट करना अच्छा है!

शायद मुझे कुछ स्पष्ट याद आया। लेकिन, क्या प्रक्रियात्मक मैक्रो विस्तार से proc_macro-defining क्रेट से किसी फ़ंक्शन को कॉल करने, एक प्रकार का उपयोग करने आदि का कोई तरीका नहीं है? (या proc_macro क्रेट से ज्ञात कोई अन्य टोकरा, FWIW)

वर्कअराउंड हैं , लेकिन AFAIU वे काम नहीं करेंगे यदि प्रक्रियात्मक मैक्रो के उपयोगकर्ता द्वारा टोकरा का नाम बदल दिया जाता है।

@Ekleog proc-macro क्रेट आमतौर पर केवल उन क्रेटों के निर्माण के उद्देश्य से संकलित किए जाते हैं जो उनका उपयोग करते हैं। वे रनटाइम निर्भरता नहीं हैं। आप संपूर्ण प्रो-मैक्रो क्रेट को एक प्रकार के कंपाइलर प्लगइन के रूप में सोच सकते हैं, न कि "सामान्य" लाइब्रेरी।

क्रॉस-कंपाइलिंग करते समय यह विशेष रूप से दिखाई देता है: जैसे बिल्ड स्क्रिप्ट, प्रो-मैक्रोज़ होस्ट प्लेटफॉर्म के लिए संकलित होते हैं, लक्ष्य एक नहीं।

@SimonSapin मैं सौंपना वास्तव में उपयोगी हो सकता है, भले ही वह प्रो-मैक्रो क्रेट न हो (उदाहरण के लिए ऊपर मेरे लिंक में, X-derive टोकरा X टोकरा से एक फ़ंक्शन का उपयोग करने का प्रयास करता है)। क्योंकि अन्यथा इसका मतलब यह होगा कि प्रो-मैक्रोज़ द्वारा उत्पन्न सभी कोड को या तो स्वयं शामिल होना चाहिए या कॉल साइट की स्थिति पर अनुमान लगाना होगा।

फिर, मैं समझ सकता हूं कि इस तरह की सुविधा के लिए रस्टक अभी तक तैयार नहीं है (क्योंकि मुझे लगता है कि यह गैर-प्रो-मैक्रो क्रेट से प्रो-मैक्रो को विभाजित करने की आवश्यकता के बिना सबसे अच्छा काम करेगा, जो कि लंबे समय तक कहीं प्रतीत होता है- टर्म रोडमैप)। लेकिन मुझे आश्चर्य है, अगर केवल TokenStreams का उपयोग करने वाले वर्तमान इंटरफ़ेस को स्थिर किया जाता है, तो क्या बाद में इस सुविधा को फिर से निकालना संभव होगा? क्या इसे PathToBeResolvedFromTopOfGeneratingProcMacroCrate टोकन प्रकार जैसी किसी चीज़ की आवश्यकता नहीं होगी? (जो बाद में जोड़े जाने पर एक महत्वपूर्ण बदलाव होगा, afaiu)

हो सकता है कि अंततः चीजों को और अधिक लचीला बनाना संभव हो, लेकिन यह काफी दूर लगता है।

इस बीच, यदि आप एक पुस्तकालय लेखक हैं, तो प्रक्रियात्मक मैक्रोज़ के लिए foo-proc-macros या foo-derive टोकरा और रन-टाइम वाली "सामान्य" foo लाइब्रेरी रखने पर विचार करें। कोड लेकिन प्रक्रियात्मक मैक्रोज़ को फिर से निर्यात करता है। इस तरह यूजर-फेसिंग एपीआई को सिंगल क्रेट में रखा जा सकता है। यह वही है जो 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 s की एक धारा है और प्रत्येक TokenTree ने Span संबद्ध किया है, जो स्कोपिंग जानकारी रखता है। सिवाय इसके कि वर्तमान में "कॉल साइट" (या खाली) के अलावा किसी अन्य क्षेत्र के लिए एक अवधि बनाने का कोई तरीका नहीं है। मूल रूप से विशिष्ट टोकरा का जिक्र करते हुए Span बनाने के एक उचित एर्गोनोमिक तरीके के साथ आने की जरूरत है।

मैंने जो कारण पूछा वह यह है कि चेकबॉक्स पर टिक नहीं किया गया है। अच्छा होगा कि आप इसे तब टिक कर दें!

#![feature(proc_macro)] स्थिर होने के साथ, इस मुद्दे का क्या बचा है?

@ jan-hudec ओह, मैंने सोचा था कि Span s केवल त्रुटि रिपोर्टिंग के लिए थे, क्योंकि शुरुआती ब्लॉग पोस्ट में Hygiene (या इसी तरह नामित) संरचना का उल्लेख किया गया था जिसने यह भूमिका निभाई थी। मैंने मान लिया था कि ये गायब हो गए थे, और जाहिर तौर पर गलत थे। धन्यवाद! :)

#![feature(proc_macro)] स्थिर होने के साथ, इस मुद्दे का क्या बचा है?

आदर्श रूप से, सभी व्यक्तिगत शेष मुद्दों के लिए नए मुद्दों को दर्ज करने की आवश्यकता है, न कि स्थिर सुविधाओं के लिए, और फिर इस मुद्दे को बंद किया जा सकता है (उसी तरह जैसे कि यह https://github.com/rust-lang/rust/issues/ के लिए किया गया था) 44660)।

ओह, मैंने सोचा था कि स्पैन केवल त्रुटि रिपोर्टिंग के लिए थे, क्योंकि शुरुआती ब्लॉग पोस्ट में एक स्वच्छता (या इसी तरह नामित) संरचना का उल्लेख किया गया था जिसने यह भूमिका निभाई थी। मैंने मान लिया था कि ये गायब हो गए थे, और जाहिर तौर पर गलत थे। धन्यवाद! :)

IIUC, स्पैन स्वच्छता संदर्भ पर नज़र रखने का प्राथमिक तरीका है।

@ मार्क-आईएम तरह का। इनमें सोर्स कोड लोकेशन इंफॉर्मेशन (यूजर-फेसिंग मैसेज/डायग्नोस्टिक्स के लिए) और सिंटैक्स कॉन्टेक्स्ट (यानी हाइजीन इंफॉर्मेशन) दोनों शामिल हैं।

इस मुद्दे को मिलने वाली चर्चा/यातायात की मात्रा को देखते हुए, क्या proc_macro_diagnostic को अपने स्वयं के ट्रैकिंग मुद्दे पर ले जाने का कोई मतलब है? मैं यह भी पता लगाना चाहूंगा कि उस सुविधा के स्थिरीकरण के लिए अवरोधक क्या हैं, और देखें कि क्या हम इसे आगे बढ़ा सकते हैं। डीजल इसका उपयोग करता है, और यह अब तक बहुत अच्छा रहा है। स्थिर पर इस सुविधा की कमी के कारण समुदाय फंकी वर्कअराउंड बना रहा है, जैसे syn का नवीनतम संस्करण compile_error! का उपयोग करके इसके स्थान पर।

@sgrif मैंने ऐसा कोई मुद्दा खोला है: https://github.com/rust-lang/rust/issues/54140।

तो मैं स्पैन और लाइन कॉलम संरचना में विधियों को स्थिर करने में मदद करने में रूचि रखता हूं। मैं पहली टिप्पणी में खुले मुद्दों को देखूंगा, लेकिन अगर कोई किसी विशेष दिशा में संकलक को नौसिखिया इंगित करना चाहता है तो मैं इसकी सराहना करता हूं: +1:

proc_macro_gen फीचर गेट ने मुझे यहां बताया, लेकिन शीर्ष पर चेक सूची में मुझे ऐसा कुछ भी नहीं दिखाई देता है जो स्पष्ट रूप से एक (proc_) मैक्रो को संदर्भित करता है जो अन्य मैक्रो परिभाषाएं उत्पन्न करता है। क्या इसका हिसाब लगाया गया है (रस्टसी के फीचर गेट के अलावा)?

@jjpe यह शायद इस समय सबसे अच्छा है कि हम उन फीचर गेट्स के लिए समर्पित ट्रैकिंग मुद्दों को बंद कर दें, यह मुद्दा काफी हद तक स्थिरीकरण की प्रारंभिक लहर के लिए समर्पित था

@alexcrichton मैं इसके साथ पूरी तरह से ठीक हूं, यह अधिक है कि proc_macro_gen सुविधा को देखने की प्रक्रिया में, इसने मुझे यहां केवल उतना ही अच्छा खोजने के लिए संदर्भित किया जितना कि इसका कोई उल्लेख नहीं है। यह मेरे लिए थोड़ा अजीब है, इसलिए मैंने इसका उल्लेख करने का फैसला किया, कम से कम।

@xieyuheng CodeString / Code भी कैसा दिखेगा यानी इसका शब्दार्थ क्या होगा?
ध्यान रखें कि TokenStream परेशान करने वाले टेक्स्ट के बजाय टोकन मूल्यों की एक श्रृंखला के अलावा स्रोत कोड शब्दशः से ज्यादा कुछ नहीं है।

TokenStream ( TokenTree ) के लिए विस्तारित API 1.29 में स्थिर है। फंक्शन-जैसे प्रो मैक्रो आयात करना 1.30 बजे स्थिर रहेगा।

ऐसा लगता है कि rustc 1.30.0-nightly (63d51e89a 2018-09-28) बाद से अलग फ़ाइल में मॉड्यूल के अंदर कोड को पार करना संभव नहीं है। यदि आप mod module; संसाधित करते हैं, तो आपको TokenStream जिसमें mod module; , WYSIWYG होता है।

मैं समझता हूं, कि प्रोसेस्ड कोड के साथ स्पैन, हाइजीन और एकरूपता को बनाए रखने के लिए यह आवश्यक है। क्या अलग फाइलों में मॉड्यूल की सामग्री के साथ काम करने का कोई तरीका है या होगा? इसकी कमी अंतिम उपयोगकर्ताओं के लिए भ्रमित करने वाली हो सकती है जब मॉड्यूल संगठन की तुच्छ रीफैक्टरिंग मैक्रो व्यवहार में परिवर्तन का कारण बनती है।

ठीक है, यह मुद्दा बहुत बड़ा है और इस बिंदु पर पहुंच गया है कि मुझे नहीं लगता कि इसे और अधिक खुला रखना और एपीआई को ट्रैक करना बहुत उपयोगी है। इसके लिए मैंने 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 - "स्वच्छता 2.0" रिपोर्ट के लिए एक तरह का कैच-ऑल, शायद खुद को शार्प करना चाहे।

इस बिंदु पर मैं इसे बंद करने जा रहा हूं, लेकिन अगर मैं किसी भी अन्य ट्रैकिंग मुद्दों को विभाजित करना भूल गया हूं तो कृपया मुझे बताएं! मैं निश्चित रूप से कुछ और फॉलो-अप खोल सकता हूं

@alexcrichton विशेषता जैसे मैक्रो के लिए उप-विशेषताओं के बारे में क्या?
https://github.com/rust-lang/rust/issues/38356#issuecomment -397095541
क्या इसके लिए कोई मुद्दा है?

@XX
ऐसी उप-विशेषताओं का भाषा विशेषता होना आवश्यक नहीं है?
derive मामले में कस्टम विशेषताओं के पंजीकरण की आवश्यकता है क्योंकि व्युत्पन्न मैक्रो अपने इनपुट से विशेषताओं को नहीं हटा सकते हैं (इनपुट अपरिवर्तनीय है)।
विशेषता मैक्रोज़ अपने इनपुट से #[other_attribute] s को हटा सकते हैं, इसलिए उन्हें कभी भी नाम समाधान नहीं मिलेगा और कभी भी "अनसुलझे विशेषता" त्रुटि की रिपोर्ट नहीं करेंगे।

(उस क्लासिक विरासत के अलावा https://github.com/rust-lang/rust/issues/38356#issuecomment-397095541 में उल्लिखित अस्थिर कस्टम विशेषताएँ अब प्रो मैक्रोज़ के साथ संगत हैं।)

@petrochenkov हाँ, स्पष्टीकरण के लिए धन्यवाद।