cc @nrc @jseyfried

#[proc_macro_attribute] 이 곧 구현되기를 바랍니다. 나는 이미 컴파일러 지원이 없다는 것을 깨닫기 전에 쾅쾅 소리를 낸 프로토타입과 테스트 사용법을 가지고 있습니다 :unamused: :

프로토타입: 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 편집: 체크리스트를 OP로 이동)

cc @nrc @petrochenkov @durka @Ralith

@jseyfried 레거시 매크로와 이름이 같은 속성을 동일한 범위로 가져오는 경우 속성을 사용하려고 하면 매크로를 속성으로 사용할 수 없다는 오류가 발생하는 문제가 발생했습니다. 둘 다 같은 범위에 있고 의도한 대로 사용할 수 있도록 이 작업을 수행할 수 있습니까?

@abonander 모든 매크로(뱅, 속성 및 파생)는 동일한 네임스페이스를 공유하므로 동일한 범위에서 동일한 이름을 가진 두 개의 다른 매크로를 사용할 수 없습니다. 그러나 해당 오류 메시지를 개선할 수 있습니다. 문제를 열어주시겠습니까?

파티에 늦어서 죄송합니다. AST가 아닌 토큰을 노출하는 방향에 만족하지만 RFC에서 제안된 특정 TokenStream API에 대해 몇 가지 우려가 있습니다.

pub enum TokenKind {
    Sequence(Delimiter, TokenStream),

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

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

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

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

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

pub enum StringKind {
    Regular,
    Byte,
}

이 API가 RFC가 병합될 때 수락된 완전한 계획으로 의도된 것인지 아니면 나중에 해결될 예시일 뿐인지 명확하지 않습니다.

일반적으로 이것은 컴파일러가 매크로 외부에서 허용하는 "정상적인" Rust 구문과는 거리가 먼 것 같습니다. 일부 매크로는 일부 임시 도메인 특정 언어를 구문 분석하려는 반면 다른 매크로는 "실제 Rust" 구문을 구문 분석하고 이해하기를 원할 것입니다.

1. (Minor) Eof 는 필요 없다고 생각합니다. Iterator 는 TokenStream 반복하는 데 사용되며 Iterator::next 이미 None 를 반환하여 반복의 끝을 알리는 데 사용됩니다.

2. (사소한) Exclamation , Dollar 또는 Semicolon 가 필요하지 않다고 생각합니다. 예를 들어 Punctuation('!') 에서 일치하는 것은 더 어렵지 않습니다.

3. (사소) 다른 사람들이 RFC PR에서 언급했듯이 문서 주석이 아닌 주석은 생략할 수 있습니다. (주석을 보존하려는 모든 사용 사례는 공백도 보존하기를 원할 것입니다.)

4. 내가 말할 수 있는 한, 다중 문자 연산자(각각 단일 토큰이어야 함)로 무엇을 해야 하는지는 여전히 미해결 질문입니다. 가능한 솔루션 은 PR 주석에 설명되어 있지만 RFC 텍스트에는 포함되지 않은 것 같습니다.

5. 숫자 리터럴이 없습니다. 매크로는 리터럴을 평가하기 위해 자체적으로 [Punct('1'), Punct('_'), Punct('2'), Punct('3'), Punct('4'), Punct('.'), Punct('5'), Punct('e'), Punct('6')] 를 구문 분석해야 합니까? 허용하는 구문이 Rust 리터럴 구문(예를 들어 중간에 _ 이 있을 수 있음)과 동일하지 않기 때문에 그들은 그렇게 하기 위해 str::parse::<f32> 를 사용할 수도 없습니다.

   여기에 안정성 문제가 있다고 생각합니다. u128 / i128 (그리고 아마도 미래에는 f128 , u256 , ...)와 같은 새로운 숫자 유형과 해당 리터럴을 변경하지 않고 도입할 수 있습니까? 토큰 API? 이를 가능하게 하는 한 가지 방법은 다음과 같습니다.

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

   아니면 다른 것일 수도 있습니다. 그러나 나는 "숫자가 존재하지 않는 척"하는 것이 좋은 방법이라고 생각하지 않습니다.

6. // Word는 유니코드 표준 부록 31에 의해 정의됩니다. -

   이 정의는 그보다 더 정확해야 합니다. UAX 31은 식별자 구문의 몇 가지 다른 변형을 지정하며 그 중 어느 것도 "단어"라고 하지 않습니다. 그러나 우리가 원하는 정확한 변형을 선택하는 것이 현재 비ASCII 식별자에 기능이 제한된 이유입니다.

   대신 "현재 컴파일러가 식별자 또는 키워드로 허용하는 모든 것"(#28979에 따라 변경될 수 있음)으로 정의해야 한다고 생각합니다. libmacro에 pub fn is_identifier(&str) -> bool 공개 API가 있을 수 있습니다.

7. 유니코드 문자열과 바이트 문자열 리터럴은 단일 토큰 변형을 공유합니다. 값의 메모리 표현이 다른 유형( str vs [u8] )을 가지기 때문에 잘못된 것이라고 생각합니다. text: Symbol 구성 요소가 소스 코드의 리터럴 슬라이스인지 또는 백슬래시 이스케이프를 해결한 후의 값인지도 명확하지 않습니다. 나는 당연히 후자여야 한다고 생각한다. (비교를 위해 \u{A0} 는 문자 그대로 나타내기 위해 둘 이상의 char 가 필요하므로 Char(char) 는 후자여야 합니다.)

높은 수준의 매크로를 작성하는 또 다른 방법은 매크로와 같은 lisp를 사용하는 것이지만 이것은 전체 rust ast에 대한 s-표현식 표현이 필요합니다.

@SimonSapin ,

다른 사람들이 RFC PR에서 언급했듯이 우리는 문서 주석이 아닌 주석을 생략하고 싶을 수도 있습니다. (주석을 보존하려는 모든 사용 사례는 공백도 보존하기를 원할 것입니다.)

하지 마세요. 구문에서 주석을 사용하고 싶은 사용 사례가 있습니다(보존은 아니지만 대신 별도의 컴파일 제품에 작성됨).

특히, 별도의 소스 파일에서 문자열 번역을 로드하는 번역 매크로를 만들고 디버그 빌드에서 부산물로 번역될 문자열 목록을 생성하고 싶습니다. 그리고 그 목록(rust-locale/rust-locale#19)에 내보낼 주석을 포함하는 방법이 필요합니다. 따라서 주석 구문을 사용하는 것이 합리적이며 매크로가 주석 구문을 볼 필요가 있습니다.

나는 그 게시물의 다른 요점에 동의합니다.

@jan-hudec
TokenKind::Comment 가 없더라도 연속 토큰 사이의 범위 내용을 보고 주석을 사용할 수 있습니다.

사용자가 의미 체계 변경에 대해 걱정하지 않고 매크로 호출에 주석을 자유롭게 추가할 수 있도록 절차적 매크로가 주석을 무시하도록 장려하기 위해 TokenKind::Comment 가 없어야 한다고 생각합니다.

@jan-hudec 속성이 솔루션에서 작동하지 않는 이유가 있습니까?

@abonander , 속성은 절대적으로 의미가 없습니다. 번역 가능한 문자열은 항목이 아닌 리터럴로 작동합니다. 그러나 컴파일하는 동안 추출하는 것은 단지 편의를 위한 것일 뿐입니다. 항상 별도의 구문 분석으로 수행할 수 있습니다. (사실, 결국 그렇게 될 수도 있습니다. 왜냐하면 크레이트에서 _모두_를 볼 필요가 있고 증분 컴파일은 이를 깨기 때문입니다).

나는 serde 파생을 기반으로 하는 절차적 매크로를 만들고 싶지만(직접적으로 serde tokenstream 함수를 호출함), serde 파생을 절차적 매크로가 아닌 라이브러리로 사용하고 싶다고 말할 수 있는 방법이 없습니다. 이것은 매크로 파생에만 국한되지 않고 '일반' 절차 매크로에도 비슷한 것이 필요하다는 것을 알 수 있습니다.

현재 내 유일한 솔루션은 serde_derive를 분기하는 것 같습니다.

문제는 Rustc의 다음 오류 메시지입니다.

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

그것을 제거하고 작동하게 만드는 것은 쉽지만 해결 방법을 잘 모르는 복잡성도 있습니다. 절차적 매크로 크레이트는 다른 절차적 매크로 크레이트에서 파생된 proc-macro를 사용하고 싶을 수도 있습니다. 다운스트림 사용자에 대한 파생을 생성하기 위해 함수를 호출합니다. 어떻게 생겼을까요? 소비하는 상자의 요청에 따라 두 가지 방식으로 상자를 연결할 수 있는 이와 비슷한 것이 현재 주변에 있습니까?

@aidanhs

절차적 매크로 크레이트는 다른 절차적 매크로 크레이트에서 파생된 proc-macro를 사용하고 함수를 호출하여 다운스트림 사용자에 대한 파생을 생성하기를 원할 수 있습니다. 어떻게 생겼을까요?

proc-macro 크레이트에서 함수(또는 절차적 매크로 이외의 다른 것)에 액세스할 수 없습니다. TokenStream -> TokenStream 함수와 해당 절차 매크로를 사용하려면 TokenStream -> TokenStream 함수를 proc-macro 아닌 별도의 크레이트에 넣어야 합니다. 해당 기능에 위임하는 proc-macro 크레이트입니다.

이 RFC는 #40939가 도착하면 대부분 구현됩니다.

proc_macro 작성자가 매크로 사용자가 크레이트 루트에 extern crate foo; 를 포함할 필요 없이 미리 결정된 크레이트 foo 항목을 사용하는 확장을 만들 수 있는 방법 제공

매크로가 아닌 항목과 해당 항목을 참조하는 절차적 매크로를 모두 포함하는 단일 상자를 제공한다고 가정합니다. #40939가 착륙하면 이 3개의 상자 패턴이 이 목표를 달성하는 관용적 방법이 될까요?

1. 매크로가 아닌 모든 항목을 foo_runtime 넣습니다.
2. 필요에 따라 foo_runtime 의 기호를 참조하여 foo_macros 에 절차 매크로를 구현합니다.
3. foo_runtime 및 foo_macros 의 항목 pub use 최종 "파사드" 상자 foo foo_macros
   
   
   
   • 이것은 사용자가 직접 가져올 유일한 상자입니다.
   
   
   • 위생 시스템이 올바른 상자를 가리키도록 매크로를 수정하기 때문에 작동합니다.
   
   

제 사용 사례에 두 개의 크레이트 를

@lfairy "two-crate" 패턴이 관용적인 방식이 될 것이라고 생각합니다.

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 pub use 항목 foo .

위생 시스템이 올바른 상자를 가리키도록 매크로를 수정하기 때문에 작동합니다.

다른 상자에서 절차 매크로를 다시 내보내도 절차 매크로의 이름이 확인되는 방식에는 영향을 미치지 않습니다.

@jseyfried : 이 재수출 트릭이 사용자 정의 파생 상품에서도 작동하는지 아십니까? 이러한 상자에는 항목을 내보낼 수 없다는 것과 정확히 동일한 제한이 있기 때문입니다.

@colin-kiegel
커스텀 파생 크레이트는 #[proc_macro_derive] 만 있는 proc 매크로 크레이트입니다.
#[feature(proc_macro)] 를 사용하면 다른 proc 매크로를 다시 내보낼 수 있는 것처럼 일반 상자에서 사용자 정의 파생 상품을 다시 내보낼 수 있습니다.

@jseyfried 현재 상황을 인지하고 있고 이상적이지 않다고 생각해서 질문을

즉, 호환성 위험을 인식합니다. 매크로에 의해 생성된 정확한 토큰트리는 안정적인 인터페이스의 일부가 되므로 serde가 패치 버전에서 Derive 를 생성하는 방법을 변경하고 취약한 매크로를 작성하면 매크로는 내 상자의 모든 새로운 사용자에 대해 손상됩니다(최악의 경우 특정 입력에 대해서만 작동하지만 일관되게 작동하는 현재의 경우 취약한 매크로와 반대).

@jseyfried

현재 화물 목록에서 foo 가져오나요? 그것은 나쁘게 들립니다(즉, 현재 바이너리에 foo 라는 이름의 2개의 크레이트가 링크되어 있다면 특히 어리석은 일을 합니까?).

@aidanhs 그것은 자체 RFC를 보증하는 주요 언어 변경/추가가 될 것입니다.

@arielb1

현재 화물 목록에서 foo 가져오나요? 나쁜 소리

예 -- 슬프게도 인용된 extern crate 이름은 위생적이지 않습니다. 즉, 해상도는 절차 매크로가 사용되는 범위에 있는 크레이트 이름에 따라 다릅니다. 다시 내보내기 트릭을 사용하여 이를 완화할 수 있지만(즉, foo 에서 foo_macros 를 다시 내보내어 foo 가 범위 내에 있음을 알 수 있음) foo 라는 두 개의 상자가 있는 경우 모호성 오류에 대비합니다.

여기에서 가장 좋은 해결책은 --target-extern 명령줄 인수를 통해 proc-macro 상자에 대한 Cargo.toml 에 1단계(즉, 대상 wrt 호스트 대 대상) 종속성을 추가하는 것입니다. 이것은 우리가 명시 적으로 나열 할 수있는 것입니다 extern crate 내부의 범위에있는 이름 quote! .

@jseyfried

proc-macro 크레이트가 "대상" 메타데이터에 종속성을 가질 것이라는 아이디어입니다. 맞습니까?

@arielb1 네,

이 RFC는 #40939가 도착하면 대부분 구현됩니다.

@jseyfried PR이

그 PR이 도착하면 안정화될 준비가 되었습니까?

아니요, 우리는 extern crate 이름을 안정화하기 전에 API에 대한 약간의 경험을 얻고 싶습니다(예: @arielb1이 지적한 이 문제 해결 ).

우리는 아마도 이 API를 크게 변경하고 싶을 것입니다. @eddyb 는 OpKind 를 모든 토큰 트리에 일반화하는 것을 제안/고려했습니다. 또한 문서 주석, 부동 소수점 리터럴 등을 처리하는 방법을 변경할 수 있습니다. 전반적으로 이 PR의 API는 아직 안정화를 고려할 만큼 성숙하지 않습니다.

@bstrie 슬프게도 파생 매크로 안정화와 같이 proc 매크로 안정화를 빠르게 추적하는 RFC(예: 토큰 스트림이 문자열 표현을 통해서만 액세스할 수 있는 제한된 API 사용)가 실패했습니다: https://github.com/rust-lang/rfcs/ 풀/1913

@est31 연기됨 -- 이 API에 대한 약간의 경험 후에 우리는 안정으로 빠르게 전환하는 데 동의할 수 있는 하위 집합에 동의할 수 있습니다.

String 기반 API는 선언적 매크로 2.0과 심하게 상호 작용하며 매크로 2.0이 없고 #[derive] 만 있는 경우에도 이미 제한적입니다. 우리는 사람들이 매크로 2.0으로 마이그레이션할 때 발생하는 문제를 피하기 위해 String 기반 API의 확산을 최대한 피하고 싶습니다.

나는 #[proc_macro_attribute] 대한 이슈 를

이것은 이제 proc_macro 크레이트 및 새 API에 대한 추적 문제이므로 몇 가지 생각도 적어 보겠습니다. 저는 proc-macro2 라는 크레이트를 공개했습니다. 이 크레이트는 안정적인 Rust에서 컴파일할 수 있는 기능을 제공한다는 점을 제외하고는 트리에 있는 proc_macro 크레이트와 완전히 동일합니다. 그런 다음 더 나은 범위 정보의 이점을 얻기 위해 야간 Rust에서 컴파일하는 기능을 사용할 수도 있습니다. 그 라이브러리는 syn 와 같은 다른 라이브러리의 기반이 되기 위한 것이며 syn 개발에서 우리는 proc_macro 직접 해결하고 싶은 몇 가지 단점을 발견했습니다.

• 몇 가지 종류의 리터럴에는 Literal 생성자가 없습니다. 이것은 문자열화와 파싱을 통해 해결되지만 문자열 API를 거치지 않고 직접 구성할 수 있다면 좋을 것입니다.
  
  
  
  • 원시 문자열 - r###" foo "###
  
  
  • 원시 바이트 문자열 - rb#" foo "#
  
  
  • 바이트 리터럴 - b'x'
  
  
  • 문서 주석 - 현재 Literal 토큰으로 표시됩니다.
  
  
• Literal 를 검사하고 값을 추출할 방법이 없습니다. 지금 우리는 to_string 리터럴에 literalext 크레이트 에 의존하고 그것을 재분석하지만 이론상 이 정보는 이미 Literal 저장되어 있고 액세스하십시오.
• 경우에 따라 토큰 매핑이 약간 이상하게 해석될 수 있습니다. 즉, 현재 문서 주석은 Literal 유형에 매핑됩니다.

여기에서 시작되는 다른 모든 문제는 그 이후로 해결되었다고 생각합니다.

로 테스트 할 때 나는 파손을 발생 #![feature(proc_macro)] 가 사용자 정의 도출에 영향을 #[proc_macro_derive(foo, attributes(foo))] . 즉, 사용자 정의 파생과 동일한 속성의 이름을 가진 사용자 정의 파생입니다. 그러한 상자 중 하나는 #[derive(error_chain)] #[error_chain(...)] struct ErrorKind { ... } 가 있는 mine-derivative-error-chain입니다. 또 다른 것은 #[derive(new)] #[new] struct S; 가 있는 파생 새입니다. 다른 사람들이 있는지 모르겠습니다.

이와 같은 코드의 경우 컴파일러는 "foo" is a derive mode 두 번째 속성에서 불평합니다. 이것은 의도적인 것입니까 아니면 고칠 수 있습니까? 의도적인 경우 사용자 지정 파생 항목의 이름을 ErrorChain 으로 바꿀 준비가 필요합니다.

@아르나비온
이것은 일반적으로 의도된 것입니다. proc_macro_attribute 는 파생 전에 확장되어야 하기 때문에 new 이 proc_macro_attribute 이면 확장이 모호합니다. 구체적으로 new 가 proc_macro_derive 되도록 허용하는 것이 가능하지만 그만한 가치가 있는지 확실하지 않습니다(미래 호환성 위험이 될 수도 있음).

이것은 일반적으로 의도된 것입니다. proc_macro_attributes 는 파생 전에 확장되어야 하므로 new 가 proc_macro_attribute 이면 확장이 모호합니다.

좋아, 내가 이름을 바꿀 수 있습니다 #[derive(error_chain)] 에 #[derive(ErrorChain)] .

구체적으로 new 가 proc_macro_derive 되도록 허용하는 것이 가능하지만 그만한 가치가 있는지 확실하지 않습니다(미래 호환성 위험이 될 수도 있음).

물론 new 이 특별한 경우를 요구한 것은 아닙니다. 이것은 내가 아는 두 개의 proc_macro_derive 중 하나의 예일 뿐입니다.

나는 특별한 경우의 평균 않았다 - 죄송합니다 @Arnavion, 내 마지막 코멘트는 깨끗한 아니었다 new 특별히하지만 허용하려면 #[derive(some_macro)] #[some_attr] struct S; 하면 some_attr 결의를 A와 proc_macro_derive . some_attr 가 proc_macro_attribute 해석되면 이는 모호성 오류여야 합니다. 오늘날 some_attr 매크로로 해석되면 모호성 오류입니다.

네, 알겠습니다.

( 이런 질문을 할 수 있는 곳이 여기였으면 좋겠습니다. )

이 상태는 어떻습니까?

• [ ] proc_macro 작성자가 매크로 사용자가 크레이트 루트에 extern crate foo; 를 포함할 필요 없이 미리 결정된 크레이트 foo 항목을 사용하는 확장을 만들 수 있는 방법을 제공합니다(PR #40939 ).

PR이 도착했지만 상자가 아직 선택되지 않았습니다. @jseyfried 는 여기에서 뭔가를 언급했으며 작동하는 것 같습니다. 그러나 use 에서는 전혀 작동하지 않는 것 같습니다.

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

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

내가 뭔가를 놓치고 있습니까? 매크로에서 가져온 extern 상자의 use 기호에 대한 관용적 방법은 무엇입니까?

use 사용할 수 없습니다( https://github.com/rust-lang/rfcs/issues/959 참조). 그러나 매크로의 경우 매번 정규화된 경로를 사용하는 것이 실제로 단점은 아닙니다. (특성을 제외하고는 생각합니다)

@parched 이 다른 문제를 연결해 주셔서 감사합니다. 내 사용 사례는 다음과 같습니다.

내 매크로에서 사용자가 match-matcher와 유사한 것을 작성할 수 있도록 하고 싶습니다. 특히, 사용자는 Term 하며 이는 열거형의 변형 이거나 일치 값을 바인딩하는 간단한 변수 이름일 수 있습니다. macro_rules! 구문으로 의사 코드를 작성하려면:

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

이제 사용자가 열거형 이름 없이 변형 이름 use my_crate::AnEnum::*; 문을 삽입합니다. 그러나 이것은 (지금은) 불가능하기 때문에 $matcher 가 열거형의 변형인지 아닌지 직접 확인해야 합니다.

내 설명이 이해되기를 바랍니다. 매크로 생성 코드에서 use 에 대한 또 다른 사용 사례를 제공하고 싶었습니다.

@LukasKalbertodt은 그냥 사용할 수 my_crate::AnEnum::$matcher => {} 에서 match ?
신경쓰지 마세요, 저는 당신의 문제입니다 -- 나는 그것을 위해 https://github.com/rust-lang/rfcs/issues/959 가 필요할 것이라고 믿습니다.

@jseyfried 아니요: $matcher 는 변형 이름(이 경우 솔루션이 작동함) 또는 match x { simple_var_name => {} } 와 같은 간단한 변수 이름이 될 수 있습니다. 후자의 경우 AFAICT가 작동하지 않습니다. (btw, 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) 가 stable에서 작동한다는 점을 제외하고 현재 안정적인 Rust의 동작과 일치합니다. 난 명시 적으로하고자하는 사용자가 사용하는 것을 문서화 한 #[macro_use] 으로 error-chain 가져 오기 전에 가져해야합니다 상자 derive-error-chain .

그러나 (1) 가 proc_macro 기능과 함께 작동하도록 사용자 정의 파생 이름을 ErrorChain 로 변경하더라도(이미 안정적인 코드에 대한 한 가지 주요 변경 사항임):

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

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

여전히 컴파일되지 않습니다. (2) 의 속성은 다음과 같은 재정의 대신 macro_rules 매크로가 사용자 정의 파생에 의해 등록된 속성과 분명히 충돌하기 때문에 macro `error_chain` may not be used in attributes 오류를 생성합니다. 첫 번째 경우.

따라서 사용자 지정 파생 항목 과 해당 속성의 이름을 모두 바꿔야 합니다. 속성은 사용자 정의 파생(각 열거형에 하나씩)보다 훨씬 더 많이(열거형의 각 변형에 하나씩) 사용되므로 예상보다 더 큰 주요 변경 사항입니다. 나는 이것이 내 자신의 구성의 까다로운 상황이라는 것을 이해합니다(사용자 정의 파생 및 해당 속성에 대해 macro_rules 매크로의 이름 재사용). 그러나 이것은 사용자 정의 파생이 시작된 이후로 안정적으로 컴파일된 코드이기도 합니다. 안정화되어 6개월 후에 문제가 될 것이라고 생각할 이유가 없었습니다.

사용자 정의 파생 자체가 macro_rules 매크로를 재정의하는 것처럼 사용자 정의 파생의 속성이 macro_rules 매크로를 재정의하도록 만들 수 있습니까? 실제로 나는 그들 사이에 어떤 모호성이 있을 수 있는지 알지 못하지만 동일한 이름의 사용자 정의 파생 후에 macro_rules 매크로를 가져올 때와 같은 이유라고 가정합니다. 모든 매크로는 어떤 종류의 매크로인지 고려하지 않고 동일한 네임스페이스를 사용합니다.

proc 매크로에 대해 이야기할 덜 형식적인 "장소"가 있습니까? #rust-proc-macro IRC 채널을 좋아하시나요? 이 기능에 대해 가끔 질문을 하고 싶지만 이 스레드를 스팸하는 것은 잘못된 것 같습니다.see_no_evil: 그리고 #rust 채널에서 대부분의 사람들은 proc-macro 및 특히 새로운 proc_macro API(불안정하고 모두). 그래서: 이 주제에 대해 논의할 곳이 있습니까?

@LukasKalbertodt #rust-internals , 아마도 또는 그냥 /r/rust에서 새 스레드를 시작하십시오.

TokenStream::from_str 절차 매크로 외부에서 사용하면 패닉이 발생합니다(예: 빌드 스크립트에서).

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

이 패닉을 암시적으로 더미 "세션"을 생성하는 것으로 대체하는 것이 가능/바람직합니까? 아니면 공용 API(안정화 경로 포함)를 추가하여 생성하시겠습니까?

다른 시스템의 매크로에 대한 문헌을 본 사람이 있습니까? 이에 대한 사람들의 생각을 듣고 싶습니다. 여기에서 Scheme에 대해 이야기하겠습니다. 이것이 제가 가장 잘 알고 있는 것이기 때문입니다.

저는 개인적으로 제 프로젝트에서 R7RS Scheme용 syntax-rules 을 구현하는 작업을 하고 있으며 syntax-case 가 비위생적인 매크로 시스템( defmacro 및 syntax-rules ). GNU Guile이 이 작업을 수행합니다. syntax-case 는 구문 개체 목록(또는 Scheme의 TokenStream 행 중 일부)에 대한 추가 조건자 유효성 검사를 수행할 수 있는 fender도 지원합니다. Mark 가 작업 중이고 Bindings as Sets of Scopes 에서 영감을 받은 것 같습니다.

또한 컴파일 타임에 임의 계산을 지원해야 하는지 여부도 논의해야 합니까? Racket은 실제로 전체 "단계" 접근 방식을 취합니다. begin-for-syntax 는 매크로 확장 동안 컴파일 타임 수준에서 정의 및 계산(?)을 허용 하는 것처럼 보입니다

Scheme에서 (datum->syntax <thing-to-copy-scope-from> <thing-to-apply-scope-to>) 를 사용하면 위생에 대한 제어가 매우 가능하므로 매크로 범위를 벗어나는 대신 즉각적인 범위 외부에 있는 개체 범위를 사용할 수 있습니다.

The Scheme Programming Language, 3rd ed. 에서 이 예제를 가져 http://www.scheme.com/tspl3/syntax.html . 이 예에서는 (include "filename.scm") 를 syntax-case 매크로로 표시하고 인터프리터가 매크로를 사용하여 파일에서 읽고 평가를 계속하도록 런타임을 설정할 수 있습니다. 여기서 더 깊은 질문은 매크로 확장 시 이러한 일이 발생하도록 매크로 매크로 시스템을 원하고 파일 가져오기 트리거와 같은 컴파일 시간 계산을 트리거하기를 원하는지 여부입니다(비록 직접 컴파일러 기능에서 발생하는 것처럼 보이지만, 그래서 아마도 우리는 이것을하고 싶지 않을 것입니다).

매크로의 한계는 무엇입니까? 컴파일 시간을 줄이고자 하는 Rust가 컴파일 시간 평가를 제한하기를 원한다고 상상할 수 있습니다(특히 무한 루프를 피함). Racket은 Lisp in Small Pieces에서 참조되는 단계를 통해 "준비자와 확장자의 탑" 접근 방식을 취했습니다. 파일 I/O 및 제한된 재귀 계산을 수행하기 위해 컴파일 타임 API에 대한 액세스 허용과 같은 것을 허용하시겠습니까? 절차적 매크로가 CSV 스프레드시트 사양을 switch 문으로 전환할 수 있도록 허용해야 합니까?

다른 시스템에 대해 듣고 싶습니다! Template Haskell은 AST를 나타내는 잘 정의된 유형을 사용하는 흥미로운 접근 방식을 가지고 있으며 Haskell의 게으름은 제어 구조에 대한 매크로 사용을 대체할 수 있다고 들었습니다.

내가 선에서 벗어나면 죄송합니다.

매크로의 한계는 무엇입니까?

이번 호에서 논의된 절차적 매크로의 경우 none . 절차 매크로는 컴파일러 확장입니다. 약간의 C++ 코드가 필요하고 clang을 통해 실행하고 결과 개체를 컴파일에 추가할 수 있습니다. 일부 SQL을 사용하고 데이터베이스를 쿼리하여 해당 결과 유형을 찾고 적절한 결과 세트를 생성할 수 있습니다. 사람들이 하고 싶어하는 실제 사용 사례입니다!

Rust에는 다른 매크로 시스템이 있습니다. 업데이트는 RFC 1584 로 승인되었으며 구현은 https://github.com/rust-lang/rust/issues/39412에서 추적합니다

@VermillionAzure , 참조한 Scheme 양식을

macro_rules 및 RFC 1584 에 따른 업데이트는 syntax-rules 와 유사합니다. 이를 개선하기 위한 제안 사항이 있는 경우 https://github.com/rust-lang/rust/issues/39412 가 이에 대해 논의하기에 가장 좋은 장소일 것입니다.

이 문제에 대한 프로시저 매크로는 define-syntax 의 일반적인 형식과 같습니다. 그리고 이 RFC( 1566 )는 매우 의도적으로 syntax-case 와 같은 것을 정의하지 않습니다 . 토큰 스트림을 변환하는 함수를 호출하는 인터페이스일 뿐입니다.

인터페이스는 syntax-case 와 같은 것이 별도의 크레이트(라이브러리)에서 구현될 수 있는 방식으로 정의되며 의도는 그렇게 하는 것입니다. 그런 성향이 있다면 마음껏 뛰어놀 수 있습니다. API를 사용하는 것이 얼마나 쉬운지 또는 어려운지에 대한 모든 프로토타입과 보고서는 모두 환영받을 것입니다.

내 생각에 아이디어는 lisp에서와 같이 함수와 같은 매크로를 정의하지만 macro_rules! 정의하는 매크로를 반환하는 매크로를 갖는 것이었습니다.

따라서 다음은 동일합니다.

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

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

이것이 syntax-rules 및 syntax-case 가 계획에서 작동하는 방식입니다.

@VermillionAzure
이것은, 당신이 원하는 무엇입니까?

@porky11 아니요, 아닌 것 같습니다. Scheme 매크로가 토론에 추가할 적절한 아이디어인지 확인하고 싶었습니다. 절차적 매크로가 Scheme의 syntax-case 매크로 시스템보다 훨씬 더 강력하기 때문에 사소하다는 것은 분명합니다. 여기에 제공된 임의의 힘의 관점에서 모든 매크로 시스템을 구현합니다.

@jan-hudec 어떤 종류의 보안 보장 없이 컴파일러 확장으로 임의의 계산을 허용하는 것이 현명합니까? 여기에서 절차적 매크로가 매우 강력할 것이라는 생각에 완전히 감명을 받았지만, Rust의 잠재적인 사용자가 이것을 패키지 사용의 단점이라고 생각할까요? 저는 보안 전문가는 아니지만 컴파일러 확장 내에서 사용되는 라이브러리의 취약점이 악의적으로 Rust 컴파일러를 공격 벡터로 바꾸는 데 쉽게 사용될 수 있습니까? 또한, 절차적 매크로에 사용되는 라이브러리에서 버그가 발생하는 경우(예: 잘못된 C 라이브러리 코드에 의해 트리거되는 segfault), 이는 segfault가 계속해서 발생하여 적절한 오류 메시지 없이 컴파일러가 실패하게 만든다는 것을 의미합니까?

컴파일러의 다른 부분에 영향을 미치지 않는 방식으로 절차적 매크로에서 발생하는 오류를 캡슐화하는 방법이 있습니까?

또 다른 아이디어: 절차적 매크로는 언제 실행됩니까? 절차적 매크로가 관련될 수 있는 부작용이 있는 코드와 상호 작용할 수 있는 경우(예: 상태 저장 외부 서버와의 통신, 외부 SQL 데이터베이스 변경, 외부 시스템에 로그인하기 위한 보안 키 가져오기) 컴파일 프로세스에 의해 절차적 매크로가 트리거되는 순서가 중요합니까?

@VermillionAzure Cargo 패키지에는 컴파일 타임에 임의의 코드를 실행하는 빌드 스크립트가 이미 있을 수 있으므로 절차적 매크로는 그런 면에서 상황을 악화시키지 않습니다. 이미 종속성을 신뢰해야 합니다. (이것은 crates.io가 변경 불가능/추가 전용이 되고 Cargo.lock 파일이 있는 경우 종속성이 자동으로 업데이트되지 않기 때문에 다소 쉬워집니다. 특정 버전만 신뢰하면 됩니다.) 그리고 빌드 스크립트가 그렇지 않더라도 존재하더라도 종속성은 여전히 ​​본질적으로 런타임에 임의의 코드를 실행할 수 있습니다. 컴파일 시간이 훨씬 더 나쁩니까?

이 토론은 관련이 있지만 다른 문제를 생각하게 합니다.

크레이트가 두 개의 proc 매크로를 정의한다고 가정합니다. foo!() 는 임시 파일을 작성하고 bar!() 는 동일한 파일을 읽습니다. 이 크레이트의 소비자는 동일한 모듈에서 foo!() 및 bar!() 를 모두 호출합니다. 그런 다음 컴파일 성공 여부는 foo!() 또는 bar!() 것이 먼저 확장되는지에 따라 다릅니다. 이 순서는 구현에 따라 정의되며 충분한 사람들이 이와 같은 코드를 작성하면 사실상 표준이 될 수 있습니다.

이것이 얼마나 문제인지 잘 모르겠습니다. 이것이 구조 필드 주문 속임수를 반복하게 될지 걱정됩니다.

@SimonSapin

나는 당신의 입장에 동의하지만 컴파일 타임 실행과 런타임 실행 사이에는 한 가지 중요한 차이점이 있음을 지적해야 합니다.

사물이 한 번 컴파일된 다음 여러 시스템에 배포되는 경향이 있기 때문에 다른 위협 모델을 제공합니다. (예: Linux 배포판 빌드 클러스터에서 유지 관리자의 부주의와 샌드박싱의 단점을 악용합니다.)

@lfairy 예, 이것은 2002년에 Racket이 겪었던 정확한 문제입니다. Racket의 최고 기여자인 Matthew Flatt는 "구성 가능하고 컴파일 가능한 매크로: 언제 원하십니까 . R. Kent Dybvig, Chez Scheme에서 일한 그는 "R6RS Libraries의 암시적 단계

@SimonSapin 컴파일 시간은 잠재적으로 훨씬 더 나쁠 수 있습니다. 컴파일러가 무작위로 충돌하거나 컴파일러에 의해 유발되는 악의적인 동작을 수행하는 경우 누군가가 "Rust의 모듈은 본질적으로 안전하지 않습니다"라는 제목의 거대한 Reddit 게시물을 작성하게 될 것입니다.

@VermillionAzure , 나는 기사를 자세히 읽지

Scheme에서 하나의 라이브러리는 함수와 매크로를 모두 제공할 수 있으므로 컴파일러는 컴파일 시간이 필요한 함수와 런타임이 필요한 함수를 올바르게 정렬해야 합니다. 그러나 Rust에서 크레이트는 절차적 매크로나 런타임 기능을 제공하므로 이 구분은 (당분간) 명백합니다.

(런타임 기능을 제공하는 크레이트는 규칙 기반(위생적인) 매크로도 제공할 수 있지만, 이는 Rust에서 별도의 메커니즘입니다)

@lfairy 가 말하는 문제는 확장기 기능의 실행 순서 중 하나입니다. Rust에서 컴파일은 개별 파일에 대해 병렬일 수 있고 증분일 수 있으므로 확장기의 실행 순서는 정의되지 않습니다. 그러나 두 기사 모두 실제로 그 문제를 다루고 있습니까? 나는 그것을 보지 못했다.

@jan-hudec 네, 맞습니다. 그러나 특정 모듈이 부작용을 일으키지 않는다는 것을 보장할 수 없다면 컴파일 타임에 부작용이 허용된다면 평가 순서는 확실히 중요합니다. 모듈이 "타입 가능"합니까?

일부 세부 사항(아래 참조)에 의존할 수 없기 때문에 절차적 매크로는 "아마도 없어선 안 되는" 부작용이 있다고 생각합니다. 기능의.

이러한 세부 정보에는 다른 proc 매크로와 비교한 실행 및 동시성 순서와 proc-macro가 증분 빌드에서 다시 실행되는지 여부가 포함됩니다. 후자의 경우 빌드 스크립트에서 rerun-if-changed 와 유사한 종속성을 선언하기 위해 무언가를 추가할 수 있습니다. 그리고 빌드 스크립트와 마찬가지로 이러한 선언은 불완전하거나 버그가 있을 수 있습니다. 모든 버그를 정적으로 방지할 수는 없습니다.

부작용에 대한 보장은 피해야 한다고 생각합니다(예: 매크로 크레이트는 부작용이 작동하는 것에 의존하는 것이 허용되지 않으며, 적용되는 모듈의 코드 변경 이외의 다른 것에 대해 다시 트리거되는 것에 의존하는 것도 허용되지 않습니다. 따라서 전역 상태가 없음).

나중에 rerun-if-changed 및 기타 사항을 지정하는 방법으로 이 요구 사항을 완화할 수 있습니다.

(여기에 다소 도움이 될 반쯤 구운 일반 빌드 스크립트/프로시저 매크로 보안 제안이 있지만 아직 작성하지는 않았습니다)

IMO proc 매크로/사용자 정의 파생은 외부에 대한 I/O 또는 기타 연결 없이 샌드박스 환경에 넣어야 하며 아마도 크레인 리프트 JIT를 사용하여 미리에서 평가해야 합니다.

@est31 좋은 아이디어지만 디젤 infer_schema와 같은 것입니다! 이미
존재하는 경우 bindgen은 파일을 읽고 프로그램을 실행해야 하며 심지어 포함해야 합니다! 그리고
환경! I/O를 사용합니다.

2017년 11월 9일 06:19에 "est31" [email protected]이 다음과 같이 썼습니다.

IMO proc 매크로/사용자 정의 파생은 샌드박스 환경에 넣어야 합니다.
외부에 대한 I/O 또는 기타 연결 없이
미리, 아마도 크레인 리프트 JIT와 함께.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/38356#issuecomment-343124957 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n5VOPdKBsu81Sp3tp2XlIQ05L865ks5s0t_PgaJpZM4LMWlc
.

#40939와 #44528이 이미 병합된 것 같습니다 ...

@mark-im이 업데이트되었습니다.

절차적 매크로가 절차적 매크로를 생성할 수 있습니까?

@VermillionAzure 나는 그것을 시도하지 않았지만 그들이 할 수 없었던 이유를 알지 못합니다. 물론, "런타임" 코드를 생성하는 proc 매크로처럼, 그것들은 사용되는 것과는 별개의 상자에 있어야 합니다.

syn에서 우리는 오늘 proc_macro::TokenNode의 제한에 부딪쳤습니다. -- 블록 구분 기호 { ... } 는 입력 TokenStream에서 하나의 Span과만 연결되므로 트리거할 방법이 없습니다. 닫는 } 만 가리키는 오류입니다. Rustc에는 이러한 제한이 없는 것 같습니다.

mod m {
    type T =
}

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

proc 매크로에서 우리가 할 수 있는 최선은 블록 내부의 마지막 토큰을 가리키거나, 전체 블록을 가리키거나, 블록 뒤의 다음 토큰을 가리키는 것입니다.

일반적인 해결책은 Span::start 및 Span::end 가 현재와 같이 LineColumn 대신 1자 Span 를 반환하도록 한 다음 Span 에서 범위의 첫 번째 줄/열로 이동합니다.

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

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

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

#43604에서 해당 API를 추가한 @abonander 를 언급합니다.

Span::start 및 Span::end는 현재와 같이 LineColumn 대신 1자 Span을 반환한 다음 Span에서 Span의 첫 번째 줄/열로 이동하는 방법을 노출합니다.

그렇게 하면 Span이 구분된 목록에 필요한 특별한 동작을 채택하게 되지만 다른 모든 범위에서는 잘못된 것입니다. 일반적으로 올바르지 않습니다. 항목을 결합하여 foo(hi) 와 같은 표현식의 범위를 얻는 것을 고려하십시오. 이제 foo 를 가리키고 sp.begin() 를 사용하려고 하지만 sp.begin() 는 foo 의 첫 번째 문자만 가리킵니다.

더 나은 솔루션은 proc_macro::TokenNode::Group 에 두 개의 범위를 추가하거나 임의의 범위를 생성할 수 있도록 하는 것입니다.

Span::begin / end 반환 유형이 변경되어야 할 수도 있습니다. https://github.com/rust-lang/rust/pull/43604#issuecomment -327643229

내 절차 매크로의 범위에 있는 것에 대해 문제를 해결하기 위해 Span::def_site() 를 얻으려고 합니다. 이것이 어떻게 작동해야하는지 오해하고 있습니까?

Span::call_site() 를 사용하고 main.rs에 MySend 정의되어 있으면 거의 동일한 코드가 작동합니다. 하지만 def_site() 작동하도록 할 수 없었습니다.

#![feature(proc_macro)]

extern crate proc_macro;

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

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

#![feature(proc_macro)]

extern crate mac;

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

fn main() {}

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

Syn 측에서 추적: https://github.com/dtolnay/syn/issues/290.

@dtolnay
여기서 문제는 MySend 가 0단계(즉, 크로스 컴파일 시 호스트 아키텍처에 대해)에서 가져오기 때문에 1단계(즉, 대상 아키텍처에 대해 컴파일할 때)에서 사용할 수 없다는 것입니다.

여기서 해결책은 proc-macro 크레이트가 1단계(대상 아키텍처) 종속성을 갖도록 하여 1단계 항목을 범위로 가져올 수 있도록 하는 것입니다.

오늘 해결 방법은 다음을 반환하는 것입니다.

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

이것을 수동으로 구성할 수도 있습니다. 저는 편의상 quote! 를 사용하고 있습니다.

위생상의 이유로 dummy / std / MySend 는 범위 내의 다른 어떤 것과도 충돌하지 않으므로 예를 들어 동일한 모듈에서 이 매크로를 두 번 이상 사용하는 것이 안전합니다. ident 는 "MySend" 등으로 안전합니다.

이 문제와 mod dummy 의 필요성과 해결 방법은 https://github.com/rust-lang/rust/issues/45934#issuecomment -344497531에 자세히 설명되어

슬프게도 1단계 종속성이 구현될 때까지 이것은 인체공학적이지 않을 것입니다.

@jseyfried 감사합니다! 작동합니다. 몇 가지 후속 질문:

• 내 이전 코멘트의 코드에서, 나는 변경하는 경우 impl_mysend_for 위한 IMPL 생성하기 Send 대신 MySend 다음 모든 것을 컴파일합니다. 이것이 해결하는 Send 는 무엇이며 0단계와 1단계의 구분에 맞지 않는 이유는 무엇입니까? 이것은 의도적으로 작동합니까 아니면 우연히 작동합니까?

• Send 와 같이 내 def_site() 토큰이 사용할 수 있는 범위에는 어떤 것이 있습니까?

• MySend 가 라이브러리에서 가져와야 하는 경우(예 serde::Serialize 파생) 최종 사용자는 Cargo.toml에 serde 가 필요합니다. extern crate serde 를 작성해야 합니다. def_site() ident 확인으로 extern crate 을 절차 매크로의 Cargo.toml에 대해 확인하고 extern crate 사용하여 call_site() ident 확인을 다운스트림에 대해 확인할 수 있습니까? 화물.톰?

extern 크레이트의 경우 proc 매크로에 의해 1단계에서 크레이트를 명시적으로 사용할 수 있어야 한다고 가정합니다.

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

@dtolnay

이전 주석의 코드에서 MySend 대신 Send에 대한 impl을 생성하도록 impl_mysend_for를 변경하면 모든 것이 컴파일됩니다. 이것은 무엇으로 해결되며 왜 0단계와 1단계 구분에 맞지 않습니까? 이것은 의도적으로 작동합니까 아니면 우연히 작동합니까?

좋은 질문. 바로 지금, 서곡은 정의 사이트의 범위에 있으며(proc-macro crate가 #![no_implicit_prelude] 가 아닌 경우) 이것은 당신이 지적한 것처럼 0단계와 1단계 구별로 인한 사고(어떤 의미에서)입니다. .

그러나 인체 공학의 경우 1단계는 proc-macro 루트에 암시적으로 std 를 포함해야 한다고 생각합니다(항상 quote!(use std::...); ). 0단계에서. 곧 1단계에서 루트에 std 를 추가하기 위한 PR이 있을 것입니다.

Send와 같은 def_site() 토큰이 사용할 수 있는 범위에는 어떤 것이 있습니까?

위에서 논의한 서곡과 (곧) std 외에 1단계의 범위에 있는 다른 유일한 것은 proc-macro 자체입니다(단계 0인 proc-macro 함수 가 아님).

예를 들어,

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

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

절차적 매크로의 Cargo.toml에 대해 def_site() ident가 있는 extern 크레이트를 만들고 다운스트림 Cargo.toml에 대해 call_site() ident가 해결되는 extern 크레이트를 만들 수 있습니까?

예, Span::def_site() 가 있는 extern 크레이트가 절차적 매크로 Cargo.toml 의 1단계(대상) 종속성에 대해 해결되어야 한다고 생각하는 것을 제외하고는 오늘의 0단계 종속성은 호스트 플랫폼용으로 컴파일된 라이브러리에 연결됩니다. . 1단계 종속성은 아직 존재하지 않기 때문에 extern crate의 이름이 비위생적으로 해석되어 지적한 대로 짜증이 납니다.

1단계 종속성이 있으면 처음에는 각 확장에서 extern crate 를 인용할 필요가 없으므로 문제가 덜할 것입니다. 그러나 여전히 수정해야 합니다. 현재 계획은 먼저 proc-macro crate의 대상 종속성을 해결한 다음 이탈을 방지하기 위해 낮은 우선 순위 경고 주기로 비위생적인 해결 방법으로 폴백하는 것입니다.

extern 크레이트의 경우 proc 매크로에 의해 1단계에서 크레이트를 명시적으로 사용할 수 있어야 한다고 가정합니다.
#[proc_macro_derive(Serialize, attributes(serde), crates(serde))]

흥미롭게도 우리는 이것을 이런 식으로 구현할 수 있습니다.

대신 1단계 크레이트가 proc-macro 크레이트 루트(예: #[phase(1)] extern crate foo; )에서 선언되어 모든 proc 매크로(예: quote!(use foo::bar); )에서 자동으로 사용할 수 있을 것이라고 생각했습니다. 어쨌든 extern crate 가 나올 예정이므로 1단계 크레이트를 모두 선언하는 것을 피할 수 있습니다. Cargo.toml의 모든 대상 종속성은 1단계의 proc-macro 크레이트 루트 범위에 자동으로 포함됩니다.

내 코드에서 이름 확인을 제어하고 오류 메시지를 제어하는 ​​두 가지 목적으로 스팬을 사용하는 것 같습니다. 이 두 가지가 불가분의 관계에 있습니까? 아니면 한 범위의 이름 확인 측면과 다른 범위의 행/열 오류 메시지 위치를 혼합하는 범위를 만드는 것이 가능합니까? 나는 이것이 일반적인 요구 사항이 될 것으로 기대합니다.

더 구체적으로 말하면, 내 사용자 정의 파생의 def_site 내 범위로 트레이트를 가져왔고 사용자 구조체의 필드에서 트레이트 메서드를 호출하려고 합니다. 필드 유형이 올바른 특성을 구현하지 않으면 오류 메시지가 해당 구조체 필드에 밑줄을 긋기를 원합니다.

컴파일하고 실행하는 def_site 범위로 메서드 호출을 생성할 수 있지만 안타깝게도 오류 메시지는 매크로 1.1에서 본 것처럼 항상 파생 속성을 가리킵니다.

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

또는 구조체 필드의 ident 또는 유형과 동일한 범위를 사용하여 메서드 호출을 생성할 수 있습니다. 이 메서드는 올바른 밑줄을 표시하지만 def_site의 범위 내 특성을 확인하는 데 실패합니다.

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

어떻게 하면 올바르게 해결하고 원하는 방식으로 오류를 표시할 수 있습니까?

@dtolnay 훌륭한 지적입니다. 감사합니다.

https://github.com/rust-lang/rust/issues/46489 를 수정하는 적절한 방법은 생성된 #[derive(…)] 토큰이 동일한 이름-해상도 범위를 갖도록 만드는 것일 수 있다고 생각합니다. 범위를 유형 정의로 사용하고 오류 메시지를 생성한 quote! {} 매크로 호출 시 오류 메시지 범위를 지정합니다.

현재 위생에 관한 이야기는 무엇입니까? 나는 (4 개월 전) 작동했던 절차 매크로와 같은 기능을 가지고 있지만 Rustc 1.24.0-nightly (b65f0bedd 2018-01-01) 현재 범위에서 인수를 찾을 수 없다고 불평합니다.

죄송합니다. 이슈 트래커를 먼저 검색했어야 했는데 방금 https://github.com/rust-lang/rust/issues/46489를 방문한 것 같습니다

나는 현재 파생(역직렬화)의 올바른 구현을 차단한다고 생각하는 #47311을 제출했습니다. 절차적 매크로는 개인 필드가 있는 구조체를 생성할 수 없습니다.

self.0 와 같은 명명되지 않은 튜플 구조체 필드에 대한 액세스는 self.x 와 같은 명명된 구조체 필드에 대한 액세스와 . 토큰의 범위에 대한 요구 사항이 다른 #47312를 제출했습니다

#47311 및 #47312는 각각 #48082 및 #48083에 고정되어 있습니다.

위의 두 PR이 검토/댓글을 기다리고 있습니다.

이제 https://github.com/rust-lang/rust/pull/41029 가 완료된 것 같습니까?

그 PR은 포기했지만 되살아났고 #48465에서 계속 작업하고 있습니다. 현재 Crater에서 기다리고 있습니다.

@petrochenkov @nrc

syntax::ext::expand 를 보면 proc_macro_attribute 가 현재 여러 컨텍스트에서 처리되고 있지 않은 것으로 보입니다.

• 블록에 ( fold_block() 는 멍청한 짓입니다)
• 문/표현식(#41475, #43988)
• extern {} 블록 내부(#48747)

RFC 1566은 속성 매크로를 적용할 수 있는 특정 AST 노드 종류를 나열하지 않으므로 거의 모든 것에 적용할 수 있어야 합니다. 그러나 그것은 약간 우스꽝스러울 수 있으므로 처리해야 하지만 처리하지 않아야 하는 것과 속성이 허용되어서는 안 되지만 현재 허용될 수 있는 위치를 명확하게 설정해야 합니다(#43988).

@abonander 의도는 proc 매크로 속성이 일반 속성이 있을 수 있는 곳이면 어디든지 사용할 수 있고 다른 곳에서는 사용할 수 없다는 것입니다. 위의 모든 사항을 포함해야 한다고 생각합니다(일부는 안정적이지 않고 proc 매크로를 안정화한다면 다른 속성에 대해 안정적인 용도만 안정화).

@nrc 는 속성이 모든 항목에 적용될 수 있다는 참조 만 표시되기 때문에 해당 위치를 열거하는 모든 위치에 있습니다. 그러나 린트 속성이 블록과 명령문에도 적용될 수 있다고 거의 확신합니다.

@nrc 는 속성이 모든 항목에 적용될 수 있다고 참조에 명시되어 있기 때문에 해당 위치를 열거하는 모든 위치에 있습니다. 그러나 린트 속성이 블록과 명령문에도 적용될 수 있다고 거의 확신합니다.

afaik은 없습니다. 모든 표현식의 속성에 대해 허용되는 RFC 및 불안정한 기능 플래그가 있지만 명령문 및 블록에서만 안정화된 것으로 생각합니다. 참조에 데이터가 없습니다.

이 문제:

안정성 검사(proc-) 매크로(문제 #34079).

이제 WRT 프로시저 매크로가 닫힙니다. 내 PR은 Macros 2.0 매크로에 대한 안정성 검사를 추가하지 않았기 때문에 문제가 여전히 열려 있습니다(비록 새로운 문제일 수 있지만).

@rfcbot fcp 병합

저는 Rust 1.28 릴리스를 위해 매크로 2.0 이야기의 하위 집합 을 매크로 1.2로 안정화할 것을 제안하고 싶습니다. Rust 1.28은 2018년 5월 10일 밤에 시작되고(이 글을 작성한 후 ~2.5주) 2018년 8월 2일에 안정화될 것입니다. FCP가 5월 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] @키문디
• [ ] @사이먼사핀
• [x] @alexcrichton
• [x] @아투론
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [x] @nrc
• [ ] @pnkfelix
• [x] @scottmcm
• [x] @sfackler
• [x] @withoutboats

현재 나열된 우려 사항이 없습니다.

과반수의 검토자가 승인하고 반대하지 않으면 최종 의견 제출 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

cc @rust-lang/compiler, 여러분도 이에 대해 매우 관심이 많으니 언제든지 이의를 제기해 주십시오. 차단 이의가 있는 경우 등록할 수도 있습니다.

안정화를 위해 제안된 API를 사용하여 proc 매크로는 모든 종류의 토큰을 쉽게 생성하거나 입력에서 출력으로 복사할 수 있지만 표면 수준에서도 토큰 스트림을 쉽게 검사할 수 없는 것처럼 보입니다. 예를 들어 Literal 는 Eq 또는 PartialEq 구현하지 않습니다. 특별한 이유가 있나요? (그것도 값을 추출하고 코드에서 처리하는 대신 지정된 상수 값과의 비교만 허용합니다.)

TokenStream 주어지면 proc 매크로 구현 내부에서 proc 매크로는 리터럴을 검사하기 위해 무엇을 할 수 있습니까? 또는 그 문제에 대해 1의 값을 추출합니까? 이것은 단순히 아직 지원되지 않습니까? 향후 지원할 계획이 있습니까?

(제안된 하위 집합의 안정화를 차단하려는 것이 아닙니다. 해당 하위 집합과 의도된 기능을 더 잘 이해하고 싶습니다.)

@alexcrichton 새 항목은
위생적이지 않다. AST에 추가된 새 항목은 다음과 동일한 네임스페이스에 들어갑니다.
모듈의 다른 항목.

저는 Rust 핵심 팀에 속해 있지 않고 과거의 모든 토론을 철저히 살펴보지는 않았지만 이것은 나에게 정말 나쁘게 들립니다. 매크로가 매크로에서만 액세스할 수 있는 도우미 항목을 생성하려는 경우 어떻게 합니까?

위생을 버리는 것보다 완전한 100% 위생을 시행하는 것이 더 낫다고 생각하지만 매크로가 특정 변수에 대해 위생을 명시적으로 옵트아웃할 수 있는 방법을 제공합니다.

@joshtriplett 리터럴에 Display impl을 사용합니다.

@joshtriplett 예 @dtolnay가 언급했듯이 literalext 와 같은 상자가 구축되는 Display 를 사용합니다. 일반적으로 API는 모든 기능을 갖춘 일류 API가 아니라 "최소한의" 수준으로 사용하도록 되어 있습니다. 그것들은 아마도 나중에 올 것입니다!

이 안정화 단계는 모든 사용 사례( Display 경우 Literal 및 이를 해석할 다른 것은 없음)를 포함하는 최소한의 기능을 제공한다는 의미에서 "최대한 최소화"하기 위한 것입니다. ).

@Pauan 좋지 는 않지만 macro_rules! 와 정확히 동일합니다. 이 하고 싶지만 아직 준비가 되지 않았습니다. Span::call_site() 생성자는 여기에서 "위생 없음"을 요청하는 핵심 핀입니다. 결국 우리는 더 많은 옵션을 안정화할 것입니다.

불행히도 "완전한 100% 위생"은 몇 년이 남았고 이 제안의 목적은 Rust 2018에서 안정적인 것을 얻는 것입니다.

@alexcrichton 그래서 지금 위생적인 ​​구멍으로 그것을 안정화시킨 다음 몇 개의 시대/시대/에디션이 나중에 그 위생적인 ​​구멍을 고칠 계획입니까?

Span::call_site() 이 존재하기 때문에 지금 완전한 위생을 가질 수 없는 이유가 있습니까? 인력/시간이 부족합니까, 아니면 RFC에서 구체화해야 하는 이론적/의미론적 문제가 있습니까?

@Pauan 은 오늘날 이미 존재한다는 의미에서 실제 "구멍"이 없음을 반복합니다. 이것은 macro_rules! 및 사용자 정의 파생과 정확히 동일한 위생 이야기입니다. 이 제안은 새로운 것을 도입하는 것이 아니라 사실상 그 확장입니다.

"완벽한 위생 이야기"가 주어지면 우리는 항상 어떤 형태의 선택 해제를 원할 것입니다. 현재 해당 옵트아웃은 Span::call_site() (효과적으로). 우리는 위생을 위한 옵트아웃 메커니즘만 안정화하고 있다는 사실만 안정화하면 됩니다. 결국 우리는 필요한 경우 항목을 완전히 위생적으로 만들기 위해 더 많은 기능을 안정화할 것입니다.

위생을 안정화하는 것은 훨씬 더 멀리 떨어져 있습니다. (AFAIK) 해결되지 않은 연구 문제가 있습니다. 인력 문제가 아닙니다.

@dtolnay 아,

cc @rust-lang/compiler, 여러분도 이에 대해 매우 관심이 많으니 언제든지 이의를 제기해 주십시오. 차단 이의가 있는 경우 등록할 수도 있습니다.

아직 검토해야 할 몇 가지 사항과 몇 가지 proc-macro API 조정이 진행 중인 PR이 있습니다.

이것은 macro_rules와 똑같은 위생 이야기입니다! 및 사용자 정의 파생.

물론, 하지만 목표 중 하나는 더 나은 매크로 시스템을 만드는 것이라고 생각했기 때문에 기존(고장나고 제한된) 시스템을 가리키는 것이 나에게 그다지 설득력있게 들리지 않습니다.

"완벽한 위생 이야기"가 주어지면 우리는 항상 어떤 형태의 선택 해제를 원할 것입니다.

물론, 하지만 제 요점은 원하는 경우 Span::call_site() 를 사용하여 위생을 깨고(따라서 macro_rules! 기능을 얻을 수 있으므로) 기본적으로 위생적으로 만들면 위생과 위생에 모두 액세스할 수 있다는 것입니다. 비위생적. 반면 비위생 상태로 안정화되면 비위생 상태 로만 고정됩니다.

결국 우리는 필요한 경우 항목을 완전히 위생적으로 만들기 위해 더 많은 기능을 안정화할 것입니다.

오히려 성가신 (혼란) 반창고 같은 그 소리 : PROC 매크로는 대부분의 경우 (하지만 항목)에서 위생 것입니다,하지만 당신은 다음 항목에 대한 위생에 수신 거부에 새로운 기능을 사용할 수 있습니다. 제가 이해하고 있는 것이 맞습니까?

(AFAIK) 해결되지 않은 연구 문제가 있습니다. 인력 문제가 아닙니다.

알겠습니다. 충분합니다. 나는 편의와 실용주의에 대한 열망을 이해합니다. 언제 까지나 계획이 결국 나중에 시대 / 시대 / 판에서 기본적으로 고체 위생을 가지고있는 한, 나는 일시적으로 나쁜 위생을 가진 괜찮아. 나는 우리가 나중에 후회할 무언가를 안정화하기를 원하지 않을 뿐입니다.

어떤 의미에서, 이미 "기본적으로 위생은,"이 기본이 아직 지원되지 않습니다 단지입니다이다. Span::call_site 는 선택 해제입니다. :)

@Pauan @alexcrichton이 말한 것을 자세히 설명하려면

식별자를 구성하려면 위생 정보가 포함된 Span 가 필요합니다. ( Term::new )

앞으로 우리는 다양한 위생 옵션을 반영하는 Span 를 구성하는 다양한 방법을 공개할 수 있습니다. 그러나 지금은 호출자의 범위를 사용하는 Span::call_site 만 노출합니다.

이렇게 하면 전체 위생 시스템이 즉시 안정화되는 것을 방지하고 나중에 위생을 추가할 수 있는 가능성을 열어둘 수 있습니다. 이 문제를 해결하는 것은 꽤 영리한 트릭이라고 생각합니다!

@rpjohnst 따라서 proc 매크로에서 새 항목을 반환하는 유일한 방법은 Span::call_site 를 사용하는 것뿐입니까?

그렇다면 완벽하게 들릴 것입니다. 이 경우 위생은 실제로 깨끗하고 이전 버전과 호환되는 방식으로 미래에 추가될 수 있습니다.

@lfairy 아, 내가 볼, 나는 그것을 사용하는 데 필요한 것을 깨달았다하지 않았다 Span::call_site , 나는 암시 적 기본 비위생적 범위가 생각했다. 설명 감사합니다! 당신이 옳습니다. 그것은 매우 영리한 속임수입니다.

따라서 더 이상 이의가 없습니다.

@alexcrichton

속성, macro_rules 및 절차
매크로는 모두 maro 네임스페이스에 있습니다.

마지막으로 #[feature(proc_macro)] 로 확인했는데 여기에 설명된 대로 파생 오류 체인 크레이트에 대한 안정적인 코드에서 이전 버전과 호환되지 않는 변경 사항이 있었습니다. 인용된 문장을 보면 매크로 1.2에서도 계속 이와 같을 것 같습니다. 그 맞습니까?

@Arnavion 오 이런, #[derive] 확장 이후까지 "속성이 아닙니다" 오류를 연기하는 것입니다.

#48644 및 #47786이 완료된 것 같습니다. 누군가 OP를 업데이트할 수 있습니까?

@alexcrichton Literal 및 친구들의 내부 데이터에 대한 액세스 허용에 대한 논의가 있었나요? 이전 버전과의 호환성을 위해 더 이상 열거형이 아니라는 것을 알지만 Literal 로 시작할 수 없는 이유가 무엇입니까?

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

다른 리터럴 하위 유형에 대해 많은 TryFrom impls를 가질 수도 있습니다.

@abonander 그것은 논의되었지만 결론은 안정화의 첫 번째 단계에 필요하게 만드는 것보다 나중에 추가하는 것입니다. Display 구현으로 crates.io에 구축할 수 있으며 나중에 추가할 여지가 있습니다.

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

@alexcrichton
proc 매크로 API 유형에 대한 !Send 및 !Sync impls는 명시적으로 작성되지 않았지만 유추되었습니다.
일부 구조체(예: Op )의 경우 추론된 impl은 https://github.com/rust-lang/rust/issues/38356#issuecomment -383693017에 지정된 것과 다릅니다.
impls를 명시적으로 추가하는 것이 합리적일 것입니다.

앗 정말 그렇습니다! 이 문제를 해결하기 위해 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 를 탈출하는 방법은 거의 없으며 thread_local! 라고 가정

하지만 Box::leak 도 존재합니다! 여전히 불안정하지만 오늘 Box::leak(Box::new(term)).as_str() 는 &'static str 반환합니다. Box::leak (cc @RalfJung)에 의해 깨진 다른 추상화가 있는지 궁금합니다.

OTOH, Term Copy 이므로 문자열 데이터를 소유 할 수 없기 때문에 이것은 복잡합니다.
우리가 제거하는 경우 Copy 에 Term , 우리는 게으른 유지할 수 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! 는 어디에 구현되어 있습니까?}

SOOO 재미있는 이야기를 @mjbshaw : 그것은에서 구현 proc_macro::quote .
rustc_metadata 는 proc_macro 라는 이름의 상자에 quote 라는 절차 매크로가 들어 있는 것처럼 가장하지만 사용된 구현은 proc_macro rustc_metadata 에 대한 링크.

아직 검토해야 할 몇 가지 사항과 몇 가지 proc-macro API 조정이 진행 중인 PR이 있습니다.

PR 검토: 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>);

OP를 약간 업데이트했지만 결과에 따라 위생과 관련된 두 가지 가능성 있는 버그처럼 보입니다.

• 위생이 이상하다
• 위생이 더 이상하다

이 스레드를 따르는 사람들을 위해 API는 @petrochenkov가 제안한 https://github.com/rust-lang/rust/pull/50473 의 원래 FCP 주석에서 변경될 수 있습니다. 지금까지의 요약은 다음과 같습니다.

• 바꾸기 Term::new 에 Term::ident 상기 입력을 검증
• Term::lifetime 추가하고 입력을 확인하십시오.
• Term::raw_ident 및 입력 확인
• Op 을 Punct
• Punct::new 에 대한 입력 확인
• Op::op 을 Punct::as_char

내가 만들 작은 API 요청(#50473 -- @petrochenkov)은 TokenStream에 토큰을 추가하는 몇 가지 방법입니다. 혹시:

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 크레이트는 여기에 제안된 API를 기반으로 합니다. 또한 @abonander가 지적했듯이 속성 매크로는 #[proc_macro_attribute] 로 선언되고 #[proc_macro] 는 foo!() 스타일 매크로 전용으로 예약됩니다.

#[proc_macro_attribute] 이름을 #[proc_attribute_macro] 또는 #[attribute_proc_macro] 됩니까?

@Zoxc 우리는 이미 #[proc_macro_derive] 안정되어 있으므로 속성 매크로에 대해 이를 따르지 않는 것이 이상할 것입니다.

우리는받을 수 PartialEq<char> 및 PartialEq<Punct> 에 대해 Punct (유사 Ident 의 PartialEq 구현)? 추가하는 것이 꽤 안전해야 할 것 같습니다. 나는 PR을 작성하게 되어 기쁩니다. 그러나 아이디어가 중단되면 하고 싶지 않습니다.

@mjbshaw PartialEq<Punct> 도 스팬을 비교할까요? PartialEq<char> 괜찮아 보입니다. OTOH.

@eddyb PartialEq 에 대해 Ident 비교하지 않습니다 스팬 (나는이 PROC-macro2 소스가 아닌 PROC 매크로 소스 알고). 스팬이 비교에 포함되는지 여부에 대해 모호하지만 Punct 및 Ident 가 이와 관련하여 유사하게 작동할 것으로 예상합니다. Punct 에는 자체 Spacing 있습니다. 비교 대상에 포함될 것입니다(다른 사람들은 다르게 생각할 수도 있음).

지금은 Punct 대해 PartialEq<char> 만 구현하는 것이 좋습니다. PartialEq<Punct> 는 나중에 해시할 수 있습니다.

@mjbshaw proc-macro2 크레이트는 proc_macro 가 업스트림에 있는 것과 정확히 같지 않을 proc_macro 추가할 수 있지만 proc_macro 에 추가하는 것은 물론 역호환이 가능하므로 최소한의 것부터 시작하고 일단 안정되면 거기에서 확장할 수 있습니다.

나는 매크로 1.2와 관련된 모든 버그에 대해 몇 가지 https://github.com/rust-lang/rust/issues/50050 이며 @petrochenkov 가 .

Gnome 클래스는 proc_macro2/syn/quote에 대한 변경 사항과 proc 매크로에서 모듈을 생성하기 위한 기능 게이트로 중단되었습니다. 지금은 해결되었습니다. 다행히도.

이 작은 생태계의 변화를 파악하려면 어떤 것들을 모니터링해야 하나요?

@federicomenaquintero 불안정한 기능을 사용하는 경우 최신 Nightly로 코드를 컴파일하고 실패할 경우 알려주는 일반 CI 작업(매일, 매주, 무엇이든 적합한 작업)을 갖는 것을 고려하십시오. (Travis-CI는 설정에서 이러한 "크론 작업" 활성화를 지원합니다.)

@SimonSapin 감사합니다, 좋은 생각입니다. 우리는 Cargo.toml에 해당 상자의 버전을 고정하지만 버전 번호를 제거하고 Cargo가 최신 버전을 다운로드하도록 해야 할 때입니다. 이것이 올바른 방법입니까?

@federicomenaquintero 이것은 점점 주제에서 http://users.rust-lang.org/ 와 같은 다른 곳에서 하십시오. 그러나 일반적인 권장 사항은 응용 프로그램( 라이브러리와 반대) 소스 코드와 함께 Cargo.lock 를 제공해야 종속성을 효과적으로 고정할 수 있습니다. Cargo.toml 에서 foo = "1.2.3" 와 같은 종속성을 선언하는 것이 권장되며 이는 암시적으로 "SemVer에 따라 호환되는 경우 해당 버전 이상"을 의미합니다.

그래서, 만들고 싶은 상자를 개발하는 데 방해가 되는 절차적 매크로 문제에 봉착했습니다.

다음을 고려하세요:

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

proc_macro 및 custom_attributes 이 모두 필요하지만 동시에 사용할 수 없기 때문에 현재 작동하지 않습니다. proc 매크로를 안정화하면 기능 플래그가 필요하지 않다는 것을 이해합니까?

다른 것은 이런 식으로 #[my_attribute] 가 잠재적으로 #[other_attribute] 가 실행되는 것을 방지하는 코드를 생성할 수 있다는 것입니다. "외부" 속성에서 #[derive(Foo)] 가 작동하는 것과 같은 방식으로 작동하는 내부 속성을 등록할 수 있다면 정말 멋질 것입니다.

더미 세션에 대한

이 패닉을 암시적으로 더미 "세션"을 생성하는 것으로 대체하는 것이 가능/바람직합니까? 아니면 공용 API(안정화 경로 포함)를 추가하여 생성하시겠습니까?

더미 세션을 갖는 것이 매우 유용할 것이라고 생각합니다. proc-macro 크레이트에 대한 단위 테스트를 작성하는 것은 거의 불가능하거나 적어도 매우 불편합니다. 또한 TokenStream::from_str 뿐만 아니라 세션이 필요한 다른 기능도 있습니다.

@alexcrichton

매크로 1.2와 관련된 모든 버그에 대해 일부 분류 작업을 수행했습니다. 대부분의 버그는 "심각한 버그" 또는 "전체 범위 관련 버그"로 분류할 수 있습니다.

https://github.com/rust-lang/rust/issues/50504 를 "심각한" 상태로 업그레이드하고 싶습니다. 모듈 문제는 더 깊은 문제의 증상일 뿐이라고 설명했습니다. proc 매크로의 확장 ID는 그렇지 않습니다. 제대로 등록되고 있습니다. 이것이 어떤 다른 결과를 가져올지 모릅니다.
근본적인 문제를 수정하는 PR이 있지만(https://github.com/rust-lang/rust/pull/51952), 수정 사항에서 회귀가 있으며 아직 살펴보지 않았습니다.

https://github.com/rust-lang/rust/pull/52081 에서 더 많은 절차적 매크로를 안정화하기 위한 PR을 게시했습니다.

@petrochenkov 는 나에게

방금 proc_macro_derive 하위 속성 문제 및 이름 지정 시스템과 상호 작용하는 방식 에 대한 매크로 이름 지정 추적 문제 에 대해 게시 proc_macro_derive 자식 속성이 범위 지정 및 이름 지정과 상호 작용하는 방식에 또 다른 문제가 있지만 여기에서 언급하는 것이 더 적절해 보입니다. 속성의 경로는 현재 안정화 과정에 있지 않기 때문에 #[derive(foo::Parent)] 가 자식 속성 #[foo::Child] 을 가질 수 있지만 파생 매크로는 표면적으로는 다음을 수행할 방법이 없습니다. 이름 조회를 수행할 수 없으므로 자식 속성이 실제로 자신의 자식인지 식별합니다. 현재로서는 쉬운 해결책이 없지만 상호 의존적인 속성의 미래를 위해 레이더에 있어야 하는 것입니다. proc_macro_attribute 속성이 유사한 조회 문제가 발생하는 방식으로 상호 작용하기를 원하지 않을 이유가 없습니다.

오늘 내 프로젝트를 컴파일하려고 했지만 아마도 이 문제와 관련된 무언가가 깨졌습니다. 모든 오류 메시지에는 "(문제 #38356 참조)" 메시지가 있었습니다. 이것이 내가 여기까지 온 방법입니다.
여기에 컴파일하는 동안 받은 오류 메시지를 포함합니다. 내 Cargo.toml도 포함합니다.

내 프로젝트가 특정 Rust nightly 버전(rustc 1.29.0-nightly (9bd8458c9 2018-07-09))에 고정되어 있기 때문에 이것이 매우 놀랍습니다. 무엇이 변경되었을 수 있습니까? 아마도 라이브러리가 업데이트 되었습니까?

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

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

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

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

capnp = "0.8"
rusqlite = "0.13"

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

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

[dev-dependencies]

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

[build-dependencies]
capnpc = "0.8"

[profile.release]
debug = true

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

error: aborting due to 63 previous errors

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

무엇이 잘못되었을 수 있으며 어떻게 고칠 수 있는지 알고 있습니까? 감사 해요!

proc-macro2 크레이트의 경우 @realcr 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 : 빠른 답변 감사합니다.
방금 야간 컴파일러를 최신 버전으로 업데이트했습니다. proc-macro-2 문제를 제거했지만 새로운 컴파일 오류가 많이 발생했습니다. 예시:

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

...

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

확인하기 위해 내 현재 버전의 rustc:

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

문제의 원인을 추적하기 위해 futures_await 에서 기본 예제를 컴파일하려고 시도했지만 작동을 멈췄습니다. 나는 우리가 이 문제를 해결할 수 있도록 거기에 문제를 제기할 것입니다.

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

불안정한 기능을 사용하고 있기 때문입니다.

@realcr 귀하의 새로운 컴파일 문제는 이 문제와 관련이 없습니다. 계속해서 주제를

@TeXitoi : 관련이 없다고 생각되면 자유롭게 편집하거나 제거하십시오. 나는 당신을 돕기 위해 최선을 다하지만 주제에 무엇이 있고 무엇이 그렇지 않은지 알기가 어렵습니다. "(문제 #38356 참조)" 오류 메시지가 저를 여기로 데려온 이유입니다.

컴파일러 버전을 업그레이드하려고 했는데 이 오류가 발생했습니다. 내 코드

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

#[macro_use(eth_abi)]
extern crate pwasm_abi_derive;

#![feature(proc_macro)] 사용하지 않았다는 오류가 표시되지만 사용했습니다!

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

@Pzixel #![feature(proc_macro)] 를 #![feature(use_extern_macros)] 로 전환하고 싶을 것입니다. 그러면 트릭을 수행해야 합니다.

절차적 매크로를 가져오기 위해 모듈 시스템을 사용해야 한다고 생각합니다. (그리고 최신 야간 컴파일러가 있는지 확인하십시오)

@alexcrichton 네, 기사 덕분에 방금 알아냈습니다. 그러나 여전히 작동하지 않습니다.

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

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

매크로에 대한 가져오기 규칙도 변경되었습니까? 아니면 왜 여기에서 불평을 시작했는지 알 수 없습니다.

절차 매크로나 컴파일러의 버그일 수 있는 @Pzixel , 이에 대한 전용 문제를 제출할 수 있습니까?

글쎄, 나는 적어도 작동하는 것처럼 보이도록 내 코드를 먼저 다시 작성해야 한다고 생각합니다. :) 지금은 그렇지 않습니다. 여러분은 이 기능으로 많은 것을 바꿨습니다. 완료되면 BRB. 사라지지 않으면 문제를 만듭니다.

@alexcrichton
토큰이 절차 매크로에 전달되기 전에 토큰에 어떤 "사전 처리"가 적용되는지 알고 있습니까?
파생 상품에는 입력 토큰을 받기 전에 $crate 제거되고 cfg 확장되어 있다는 것을 알고 있습니다(또한 문자열을 통한 왕복은 완전히 무손실은 아니지만 수정할 수 있음).

새로 안정화된 절차 매크로에서 이러한 일이 발생하지 않고 정확하게 입력 토큰을 받는지 확인해야 합니다(모듈로 버그).

@alexcrichton 죄송합니다. cargo expand 는 어떤 이유로 이 상자에서 작동하지 않습니다. 문제가 내 쪽인지 컴파일러 쪽인지 확인할 수 없습니다. 그래서 나는 이 가능성이 완전히 배제되지 않을 때까지 계속 나 자신을 탓할 것이다.

@petrochenkov proc-macros의 확장은 현재까지 꽤 잘 검증되었으므로 이름 확인 부분보다 그것에 대해 훨씬 덜 걱정합니다. 저는 전처리에 대해 개인적으로 알지 못하지만 파생 상품이 마지막으로 실행되고 cfgs가 먼저 실행되고 그렇지 않으면 대부분 반복적인 확장 순서가 있다는 것을 알고 있습니다.

감사하는 것이 좋다는 점에는 동의합니다!

어쩌면 내가 명백한 것을 놓쳤을 수도 있습니다. 그런데 절차적 매크로 확장에서 proc_macro를 정의하는 크레이트에서 함수를 호출하거나 유형을 사용하는 등의 방법은 없나요? (또는 proc_macro 크레이트, FWIW에서 알려진 다른 크레이트)

해결 방법 이 있지만 AFAIU는 절차 매크로 사용자가 크레이트 이름을 바꾸면 작동하지 않습니다.

@Ekleog proc-macro 크레이트는 일반적으로 이를 사용하는 크레이트를 구축 할 목적으로만 컴파일됩니다. 런타임 종속성이 아닙니다. 전체 proc-macro 크레이트를 "일반" 라이브러리가 아닌 일종의 컴파일러 플러그인으로 생각할 수 있습니다.

이것은 특히 크로스 컴파일할 때 볼 수 있습니다. 빌드 스크립트와 마찬가지로 proc-매크로는 대상 플랫폼이 아닌 호스트 플랫폼용으로 컴파일됩니다.

@SimonSapin 나는 당신에게 동의하지만 proc-macro 크레이트가 아니더라도 크레이트가 제공하는 기능에 작업의 일부를 위임하는 것이 매우 유용할 수 있습니다(예: 위의 링크에서 X-derive crate는 X 크레이트의 함수를 사용하려고 시도합니다. 그렇지 않으면 프로시저 매크로에 의해 생성된 모든 코드가 자체 포함되거나 호출 사이트의 상태를 가정해야 함을 의미하기 때문입니다.

그런 다음, 나는 Rustc가 아직 이런 종류의 기능을 사용할 준비가 되지 않았다는 것을 이해할 수 있습니다. 기간 로드맵). 하지만 현재 TokenStreams 만 사용하는 인터페이스가 안정화되면 나중에 이 기능을 개조할 수 있는지 궁금합니다. PathToBeResolvedFromTopOfGeneratingProcMacroCrate 토큰 유형과 같은 것이 필요하지 않습니까? (나중에 추가되면 주요 변경 사항이 될 것입니다. afaiu)

결국에는 상황을 더 유연하게 만드는 것이 가능할 수도 있지만 이는 상당히 먼 이야기 같습니다.

그동안 라이브러리 작성자라면 절차적 매크로용 foo-proc-macros 또는 foo-derive 크레이트와 런타임이 포함된 "일반" foo 라이브러리를 고려하십시오. 코드를 생성할 뿐만 아니라 절차적 매크로를 다시 내보냅니다. 그렇게 하면 사용자 대면 API를 단일 상자에 보관할 수 있습니다. 이것은 serde 가 하는 일입니다(일부 구성에서) https://github.com/serde-rs/serde/blob/v1.0.71/serde/src/lib.rs#L304

이 해결 방법이 여전히 사용자가 루트 상자의 이름을 바꾸는 문제(예: serde의 추적 문제 )를 해결하지 못한다는 점을 지적할 가치가 있습니다.

#![feature(proc_macro)] 는 1.29.0 이후 안정화된 것으로 표시됩니다. 이것은 의도된 것입니까?

@CAD97 , 확실히. https://github.com/rust-lang/rust/commit/65f3007fa8a08daf77f2b8382a56eb80cb277131 및 https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252 참조

@Ekleog , TokenStream 는 TokenTree 의 스트림이고 각 TokenTree 에는 범위 지정 정보를 전달하는 Span 가 연결되어 있습니다. 현재 "호출 사이트"(또는 비어 있음) 이외의 다른 범위에 대해 Span을 생성할 방법이 없다는 점을 제외하고. 기본적으로 특정 크레이트를 참조하여 Span 를 생성하는 합리적인 인체공학적 방법을 찾는 것이 필요합니다.

내가 묻는 이유는 확인란이 선택되어 있지 않기 때문입니다. 그럼 체크해제해주시면 좋을 것 같아요!

#![feature(proc_macro)] 안정화되면 이 문제에 무엇이 남아 있습니까?

@jan-hudec 오, 초기 블로그 게시물에서 이 역할을 하는 Hygiene (또는 이와 유사한 이름) 구조체를 언급했기 때문에 Span 는 오류 보고용일 뿐이라고 생각했습니다. 나는 이것들이 사라졌다고 생각했고 분명히 틀렸다. 감사 해요! :)

#![feature(proc_macro)]가 안정화되면서 이 문제에 무엇이 남았습니까?

이상적으로는 안정화된 기능이 아닌 나머지 모든 개별 문제에 대해 새로운 문제를 제출해야 하며 그런 다음 이 문제를 닫을 수 있습니다(https://github.com/rust-lang/rust/issues/에서와 동일한 방식으로). 44660).

오, 초기 블로그 게시물에서 이 역할을 하는 Hygiene(또는 유사한 이름의) 구조체에 대해 언급했기 때문에 Spans는 오류 보고만을 위한 것이라고 생각했습니다. 나는 이것들이 사라졌다고 생각했고 분명히 틀렸다. 감사 해요! :)

IIUC, Span은 위생 컨텍스트를 추적하는 기본 방법입니다.

@mark-im 일종의. 여기에는 소스 코드 위치 정보(사용자 대면 메시지/진단용)와 구문 컨텍스트(즉, 위생 정보)가 모두 포함됩니다.

이 문제에 대한 토론/트래픽의 양을 감안할 때 proc_macro_diagnostic 을 자체 추적 문제로 이동하는 것이 합리적입니까? 나는 또한 그 기능의 안정화를 위한 차단기가 무엇인지 파악하고 그것을 통과할 수 있는지 확인하고 싶습니다. 디젤은 그것을 사용하고, 지금까지 훌륭했습니다. 안정판에 이 기능이 없기 때문에 커뮤니티에서 compile_error! 를 사용하는 syn의 최신 버전과 같은 펑키한 해결 방법을 만들게 되었습니다.

@sgrif 나는 그런 문제를 열었습니다: https://github.com/rust-lang/rust/issues/54140.

그래서 저는 Span 및 LineColumn 구조체의 메서드를 안정화하는 데 도움을 주고 있습니다. 첫 번째 의견에서 미해결 문제를 살펴보겠지만 누군가가 초보자에게 컴파일러를 특정 방향으로 가리키고 싶다면 감사하겠습니다. +1:

proc_macro_gen 기능 게이트는 여기를 지적했지만 상단의 체크리스트에는 다른 매크로 정의를 생성하는 (proc_) 매크로를 분명히 참조하는 항목이 없습니다. 이것이 설명되었습니까(rustc의 기능 게이트 제외)?

@jjpe 아마도 현재로서는 해당 기능 게이트에 대한 전용 추적 문제를 분리하는 것이 가장 좋을 것입니다. 이 문제는 대부분 안정화의 초기 물결에 전념했습니다.

@alexcrichton 나는 그것에 대해 완벽하게 괜찮습니다. proc_macro_gen 기능을 보는 과정에서 언급하지 않는 것만큼 좋은 것을 찾기 위해 나를 여기로 추천했습니다. 그것은 나에게 약간 이상하므로 적어도 언급하기로 결정했습니다.

@xieyuheng CodeString / Code 는 어떻게 생겼을까 요? 즉, 의미 체계는 어떻게 될까요?
TokenStream 는 귀찮은 텍스트라기보다 일련의 토큰 값을 제외하고는 그대로 소스 코드에 불과합니다.

TokenStream ( TokenTree )에 대한 확장 API는 1.29에서 안정적입니다. 함수형 proc 매크로 가져오기는 1.30에서 안정적입니다.

rustc 1.30.0-nightly (63d51e89a 2018-09-28) 이후로 더 이상 별도의 파일에서 모듈 내부의 코드를 순회할 수 없는 것 같습니다. mod module; 를 처리하면 mod module; , WYSIWYG를 포함하는 TokenStream 를 얻게 됩니다.

나는 이것이 처리된 코드와의 범위, 위생 및 일관성을 유지하기 위해 필요하다는 것을 이해합니다. 별도의 파일에 있는 모듈의 내용으로 작업하는 방법이 있거나 없을 것입니까? 모듈 구성의 사소한 리팩토링으로 인해 매크로 동작이 변경될 때 최종 사용자에게 이 기능이 없으면 혼란스러울 수 있습니다.

좋아, 이 문제는 방대 하고 더 이상 열려 있고 API를 추적하는 것이 너무 유용하지 않다고 생각하는 지점에 이르렀습니다. 이를 위해 https://github.com/rust-lang/rust/pull/54728 을 열어 이 문제를 보다 세분화된 여러 추적 문제로 나눕니다.

• https://github.com/rust-lang/rust/issues/54722 - quote! 매크로
• https://github.com/rust-lang/rust/issues/54723 - Ident::new_raw
• https://github.com/rust-lang/rust/issues/54724 - Span::def_site
• https://github.com/rust-lang/rust/issues/54140 - proc_macro 및 진단
• https://github.com/rust-lang/rust/issues/54725 - proc_macro::Span 검사
• https://github.com/rust-lang/rust/issues/54726 - 사용자 정의 내부 속성 허용
• https://github.com/rust-lang/rust/issues/54727 - "위생 2.0" 보고서에 대한 일종의 포괄적이며 자체적으로 샤딩되기를 원할 수 있습니다.

이 시점에서 나는 이것을 닫을 것이지만 다른 추적 문제를 분리하는 것을 잊은 경우 알려주십시오! 나는 확실히 더 많은 후속 조치를 열 수 있습니다

@alexcrichton 속성과 같은 매크로의 하위 속성은 어떻습니까?
https://github.com/rust-lang/rust/issues/38356#issuecomment -397095541
이에 대한 문제가 있습니까?

@더블 엑스
이러한 하위 속성이 반드시 언어 기능일 필요는 없습니까?
derive 의 경우 파생 매크로가 입력에서 속성을 제거할 수 없기 때문에 사용자 정의 속성 등록이 필요합니다(입력은 변경할 수 없음).
속성 매크로는 입력에서 #[other_attribute] 제거할 수 있으므로 이름 확인에 도달하지 않으며 "확인되지 않은 속성" 오류를 보고하지 않습니다.

(https://github.com/rust-lang/rust/issues/38356#issuecomment-397095541에 언급된 고전적인 레거시 불안정한 사용자 정의 속성은 이제 proc 매크로와 호환됩니다.)

@petrochenkov 예, 설명해주셔서 감사합니다.