Rust: '매크로 1.1'추적 문제 (RFC # 1681)

수행해야 할 작업에 대한 체크리스트로 문제 설명을 업데이트했습니다. 완전하지는 않지만 90 % 정도는 얻을 수있을 것입니다.

좋아요, 오늘 이것을 살펴보고 얼마나 멀리 있는지 보겠습니다.

cc https://github.com/rust-lang/rust/pull/35957 , 구현

# 35957에서 : librustc_macro 크레이트의 이름을 좀 더 알려줘야합니다. 특히, 이것은 모든 매크로 작성자를위한 필수 요소를 포함하는 수명이 긴 상자이므로 rustc_macro (적어도 내 마음에는)로 제한하는 것은 약 1.1 아이디어에 불과한 것 같습니다. 나는 이전에 이것을 위해 libmacro를 원했지만 macro 는 예약어이기 때문에 불가능합니다 (그리고 우리는 그것을 미래의 키워드로 원할 수도 있습니다). @cgswords 와 저는

@nrc : 좋아, 명명에 대한 내 즉각적인 생각 :

• extern crate macros; -짧고 달콤하지만 매크로를 작성하기위한 지원 코드가 아닌 포함 된 매크로로 읽을 수 있습니다.
• extern crate macro_runtime; -깡통에 적힌 그대로
• extern crate metarust; -Rust에서 작동하기 위해 Rust에 대해 Rust를 작성하세요.
• extern crate bikeshed; -절차 적 매크로를 사용하면 원하는 색상의 Rust를 가질 수 있습니다!
• extern crate macrame; - "매크로 메이크 [r]"처럼 들립니다. 원시 라이브러리에 대한 미래의 "멋진"API를 위해 남겨 두는 것이 좋습니다.

@nrc 이 질문의 중요한 측면은 libproc_macro 를 사용하면 "절차 적 매크로"에 대해 열심히 노력하고 있습니다. 술어. 나는 여기서 강한 의견을 가지고 있지 않지만, 우리가 용어의 공간을 공개적으로 탐구했는지는 확실하지 않습니다.

명확하게 말하면, 오늘의 macro_rules 가 단순히 "매크로", 즉 "매크로"가 의미하는 기본 값이지만 "절차 적 매크로"를 한정해야한다고 생각하십니까? 그것은 나에게 꽤 합리적인 계획 인 것 같습니다. 그리고 그 세계에서는 libproc_macro 이 libmacros 보다 낫다고 주장합니다.

여기서 내 생각은 모든 매크로가 "매크로"이며 구현에 따라 구분해야 할 때 (사용법은 모든 종류에 대해 정확히 동일해야 함) "프로 시저 매크로"와 "예제에 의한 매크로"를 사용한다는 것입니다. "구문 확장"과 "컴파일러 플러그인"을 완전히 제거하고 싶습니다 (그리고 언젠가는 후자를 실제 플러그인에 재사용).

그러나 예, 저는 "절차 적 매크로"용어를 강력히 따르고 싶습니다.

@nrc 나에게 좋은 의미가 있습니다! "예제에 의한 매크로"는 다소 다루기 어렵지만 매우 연상적이고 직관적 인 용어이기도합니다. "절차 적 매크로"에 대한 나의 한 가지 걱정은 "절차"가 Rust에서 존재하지 않는다는 것입니다. 좀 더 직접적으로 연결하는 방법이 있는지 궁금합니다. "함수 매크로"는 옳지 않지만 내가 의미하는 바를 이해할 수 있습니까?

예, 완벽하지는 않지만 Rust 외부에서 잘 알려진 / 사용 된 용어라는 점을 감안할 때 우리 자신의 용어를 만드는 것보다 낫다고 생각합니다. "프로 그래 매틱 매크로"는 가능하지만 "프로 시저"를 선호합니다.

"절차 적 매크로"와 가장 가까운 것에 대한 Perl의 용어는 "소스 필터"이며, 이는 특히 AST에서 토큰으로의 전환과 함께 매우 적합한 설명입니다.

아마도 '구문 변환기'또는 '프로 그래 매틱 매크로'가 이름만큼 잘 작동할까요? 그러나 절차 적 매크로에는 문제가 없습니다.

"절차 적"은 이미 사람들이 이것을 부르는 것이고, 특히 "예를 들어 매크로"와는 대조적으로 그것이 의미하는 바를 분명히 이해하고 있다고 생각합니다. 나는 다른 이름을 찾는 것에 대해 걱정하지 않을 것입니다.

정기적으로 사용되는 "절차 적 매크로"(또는 "사용자 지정 매크로")라는 용어를 좋아합니다. 저는 특히 _macro_라는 단어를 사용하여 "일반 매크로"와 같은 방식으로 (결국 ...) 사용할 수 있음을 분명히합니다. 이러한 이유로 저는 "소스 필터"를 좋아하지 않습니다 (또한 필터가 데이터를 삭제하는 것이 아니라 변환하지 않을 것으로 예상하지만 용어가 둘 다에 사용된다는 것을 알고 있습니다).

libproc_macro 또는 libmacros 괜찮습니다. 나는 쉽게 피할 수있을 때 상자 이름에 _ 를 넣는 것을 좋아하지 않기 때문에 후자를 선호합니다. =)

한 가지 질문 : 비절 차적 매크로에서 사용할 수있는 "지원 루틴"을 기대 한 적이 있습니까? 그런 계획은 알지 못합니다.하지만 그렇게했다면 같은 상자에 넣어야한다면 libmacros 가 더 나은 이름이 될 것입니다. =)

(예를 들어 열렬한 확장 RFC에서 @dherman 의 의견 에 대해 약간 생각하고 있습니다.)

@nikomatsakis : 관련이 있지만 미묘하게 다른 질문은 https://github.com/rust-lang/rfcs/pull/1561#discussion_r60459479- 절차 적 매크로의 구현 함수가 호출 할 수 있기를 원 할까요? 다른 절차 적 매크로의 구현 기능?

나는 하나의 커스텀 파생물이 다른 것을 호출하도록 허용하고 싶어한다는 것을 쉽게 알 수 있으며, 그것은 본질적으로 그러한 "지원 루틴"으로 사용될 수있는 절차 적 매크로 정의 자체를 만들 것이다.

하지만 예, @dherman 의 gensym 예제가 꽤 매력적이라고 ​​생각합니다. 물론 위의 질문에 대한 답이 "예"이면 gensym은 매크로 (매크로별로 사용할 수 있음)와 지원 함수 (절차 적 매크로에서 사용할 수 있음)입니다.

체크리스트의 모든 "화물 통합"상자를 선택해야하는화물 PR https://github.com/rust-lang/cargo/pull/3064 가 있습니다.

화물 PR에 대한 의견을 남겼지 만, 우리는 다른 유형의 _package_가 아닌 다른 유형의 _dependency_를 원한다고 생각합니다. 첫째, 나는 이것이 단지 미적으로나 인체 적으로 더 낫다고 생각하지만 그것은 단지 내 의견입니다. 하지만 두 가지 구체적인 이유도 있습니다.

• 공개 및 비공개 부서가있는 미래에는 절차 적 부서의 공개 부서와 일반 공공 부서가 일치 할 필요가 없다는 것을 아는 것이 중요합니다. 예
• 인라인 절차 적 매크로 / 준 인용을 통해 향후에는 컴파일 타임에 모든 라이브러리를 사용할 수 있습니다.
• > 우리는 절차 적 매크로의 구현 함수가 다른 절차 적 매크로의 구현 함수를 호출 할 수 있기를 원합니까?

이것이 보여 주듯이 동일한 상자는 절차 적 매크로의 다른 상자의 일반 dep이거나 다른 상자의 macro dep 일 수 있습니다.

serde는 작동합니까?

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

(일부 경우 # 36211 컨테이너 속성 제외)

@dtolnay 업데이트에 감사드립니다!

이 매크로에 대한 문서가 있습니까? 나는 그것들을 사용하는 유일한 예가 serde라고 생각합니다. 맞습니까?

OK화물이 착륙했습니다. 괜찮지 만 안정화되기 전에 https://github.com/rust-lang/rust/issues/35900#issuecomment -243976887을 다시 방문하는 것이 좋습니다. [그 가치가 무엇인지, 나는 이것을 원래 RFC에서 가져 오려고했지만 잊었다.]

"예제 매크로"와 "프로 시저 매크로"가 각각 "선언 매크로"와 "명령어 매크로"로 더 잘 분류 될 수 있다고 생각합니다. 이것은 프로그래밍 언어의 더 널리 알려진 선언적 / 명령 적 분류와 유익한 유사점을 제공합니다. 명령형은 절차의 상위 집합 또는 동의어로 취급되므로 "절차 적 매크로"용어에 익숙한 사람들이 점프를 할 수있을만큼 충분히 가까워 야합니다. 또한 녹 자체에서 절차 / 기능 / 방법 개념과의 혼동을 피해야합니다.
이 이름 지정 체계는 macro_imp 상자와 모듈을 macro_rules 병렬로 제공합니다. macro_rules 는 결국 더 일반적인 macro_dec 상자의 모듈이 될 수 있습니다.

@nrc , "실제 플러그인"을 언급 할 때 metacollect 및 clippy 같은 것 , rustw , Rust 언어 서버 같은 것 또는 다른 프로그램 범주를 포함합니까?

그만한 가치가있는 것은 "예제 별"이름을 약간 싫어합니다 ( $foo 패턴은 제 마음에 "예제"가 아니기 때문입니다). 선언적 대 명령 적 소리가 나에게 더 좋습니다.

이것을 가지고 놀면서 한 가지 문제를 발견했습니다. Rust가 제공하는 파생물이 때때로 컴파일러가 무시할 수있는 속성을 추가하는 것처럼 보입니다. 이 컨텍스트는 사용자 지정 파생을 통과 할 때 손실됩니다. 사용자 지정 파생으로 주어진 식별 기능이 작동하지 않을 것으로 예상하지만 #[structural_match] 속성이 추가되는 데 오류가 발생합니다.

복제 스크립트

( demo_plugin 라는 상자에 있음)

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

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

(다른 상자에서)

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

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

#[derive(Eq)] 하면 모든 것이 제대로 작동합니다.

@sgrif 아 예 정말로 나를 상기시켜 주셔서 감사합니다!

여기에 몇 가지 일이 있습니다.

• #[derive(PartialEq, Eq)] 를 사용하면 컴파일러는 PartialEq 파생이 실제로 해당 계약을 이행한다는 것을 정적으로 이해하기 때문에 #[structural_match] 자동으로 추가합니다.
• #[rustc_copy_clone_marker] 가 추가 된 #[derive(Copy, Clone)] 에서도 유사한 속성이 발생한다고 생각합니다.
• 현재는 이러한 속성의 범위가 "내부 불안정을 허용합니다"라고 표시되기 때문에 작동합니다. 그러나 구문 분석 및 재분석 할 때 스팬 정보가 손실됩니다.

따라서 우리가 할 수있는 몇 가지 솔루션은 다음과 같습니다.

• 관습 적으로 사용자 정의 파생이 먼저 있다고 말합니다. 예 : #[derive(Foo, Eq, PartialEq)]
• 이러한 속성을 생략하려면 사용자 정의 파생에 의존하십시오.
• 사용자 정의 파생을 감지하면 사용자 정의 속성을 내 보내지 마십시오.
• 컴파일러에서 완전히 다른 메커니즘을 사용하여 이러한 속성이 말하는 내용을 전달하지만 AST 자체를 통해서는 안됩니다.

나는 이러한 속성을 방출하지 않거나 다른 메커니즘을 사용하는 것을 선호합니다. 하지만 #[derive(Copy, Foo, Clone)] 도 작동해야하므로 (정의를 변경할 수있는 사용자 정의 코드가 중간에서 실행 됨) 정말 까다 롭습니다.

내가 선호하는 행동 방침은 사용자 지정 파생을 감지하면 이러한 속성을 내 보내지 않는 것입니다. 그러나 그것도 사소하지 않을 수 있습니다. 지금은 "사용자 지정 우선 및 표준 마지막"규칙으로 충분하지만 안정화하기 전에이 문제를 해결해야한다고 생각합니다.

면책 조항 : 저는 컴파일러의 외부보기 만 가지고 있습니다. 그래서 제가 모르는 것이 많이 있습니다. ^^

그러나 내가 이해하는 바에 따르면 매크로 1.1 사용자 정의 파생의 현재 접근 방식은 일시적인 해결 방법과 비슷합니다. 임시 해결 방법은 "아주 잠시"로 번역 될 수 있습니다. 그러나 장기적으로 (= macros 2.0) 우리는 더 이상 문자열 파싱 왕복을하지 않을 것이며, 이는 현재 스팬 정보의 손실로 이어집니다. AST의 숨겨진 속성이 매크로 2.0 세계에서 그렇게 나쁜 것인지 궁금합니다. 컴파일러에 대한 더 많은 내부 지식을 가진 사람이 말할 수있을 것입니다. 이러한 숨겨진 속성이 미래의 세계에서 실제로 의미가 있다면, 저는 관습 적으로 사용자 정의 파생을 앞에 배치하여 해결 방법을 찾아야한다고 주장합니다. 어쨌든 모든 것은 이미 해결 방법입니다.

@ colin-kiegel 우리가 지금하고있는 일이 미래를 보장하는 것이 아니라는 점에서 당신이 옳다고 믿습니다. 예를 들면 다음과 같습니다.

#[derive(Eq, Foo, PartialEq)]

오늘은 Eq 구현을 추가 한 다음 Foo 대한 사용자 지정 코드를 실행 한 다음 PartialEq 구현을 추가합니다. 구조는 Eq 에서 PartialEq 사이에서 _change_ 할 수 있으므로 #[structural_match] 에 의해 추가 된 Eq 는 Foo 실행 후 실제로 올바르지 않을 수 있습니다.

그런 의미에서 나는 그들이 어떤 경우에도 반드시 미래 보장이 아니라는 데 동의합니다!

내 느낌은 구조적 변화에 의존하는 관습 파생물은 일반적으로 숨겨진 속성과는 독립적으로 잘 구성되지 않는다는 것입니다. v2.0 사용자 정의 파생이 항목의 구조를 변경할 수 있습니까? 아니면 장식에만 제한됩니까?

예, #[derive] 의 합리적 구현이 원래 구조의 구조를 유지한다고 생각하지만 능력은 항상 거기에있을 것입니다 (TokenStream-> TokenStream 인터페이스에 내재).

구조가 변경되지 않도록 출력 토큰 스트림에 구조 자체가 포함되지 않도록 요구할 수 있다고 생각하지 않습니다. 입력 구조체 TokenStream은 변경 불가능한 접두사입니까? 큰 문제는 빌드가 완료된 후 플러그인이 사용하는 인식되지 않는 속성을 무시하는 것입니다. 아마도 각 # [derive ()]는 그들이 이해하는 속성이 시작해야하는 접두사 (예 : # [derive (Foo)]에 접두사 Foo_가 있음)를 가질 수 있으며, 각 사용자 정의 파생을 처리 한 후 해당 속성을 제거합니까?

@mystor 예, 그 접근 방식의 문제는 인식 할 수없는 속성이므로 전체 구조체를 입력으로 사용합니다. 일반적으로 특정 접두사 / 접미사 / 등록 등에 의존하는 것보다 더 유연합니다.

v2.0 사용자 정의 파생이 사용자 정의 속성을 _used_로 표시 할 수있는 경우 나머지 항목 토큰 스트림에 대한 _read-only_ 액세스로 제한 될 수 있습니다. 이렇게하면 사용자 지정 파생의 더 나은 구성 가능성이 IMO를 보장 할 수 있습니다. v2.0 매크로가 항목의 구조를 변경해야하는 경우 다른 API를 사용해야하지만 사용자 지정 파생이 아닙니다. 이렇게하면 #[structural_mach] 문제와 (사용자 정의) 파생 순서가 매크로 1.1에서만 나타납니다. 그게 말이 되겠습니까?

또 다른 문제. 구조체에 두 개의 다른 사용자 지정 파생이 있고 두 번째가 패닉 상태 인 경우 오류 범위는 당황한 것이 아니라 첫 번째 것을 가리 킵니다.

복제 스크립트

demo_plugin 라는 상자

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

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

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

다른 상자에

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

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

Bar 당황하더라도 오류가 Foo 강조 표시됩니다.

@sgrif 보고서에 감사드립니다! 이 문제에 대한 설명을 업데이트했으며 매크로 1.1과 관련된 모든 미해결 문제도 추적 할 수 있기를 바랍니다.

흠, #[structural_eq] 와 사용자 정의 파생의 상호 작용은 이전에 생각하지 못했던 것입니다. 오히려 나를 괴롭힌다!

이 토큰 스트림에 '추가'텍스트 방법을 가진 것은 ... 그것은 스팬 정보를 보존 것없이이 문제를 방지하려면 하루의 끝에 더 나은 인터페이스가 될 수 있음을 나에게 보인다?

보다 일반적인 인터페이스의 한 가지 장점은 패키지가 필드에 속성을 가질 수 있도록하여 매크로가 실행될 때 제거 될 수 있다는 것입니다. 이것은 사용자 지정 파생 매크로가 원본 항목을 변경하도록 허용하는 유일한 실제 사용 사례입니다.

인터페이스 질문은 사용자 정의 파생이 '다른 매크로'가되기를 원하는지 여부에 달려 있다고 생각합니다.이 경우 다른 절차 적 매크로 (원래 항목을 수정하려는 경우)와 동일한 인터페이스를 갖는 것이 중요해 보입니다. 또는 특수 인터페이스가있는 자체 여야하는지 여부.이 경우 더 제한적인 (추가) 인터페이스가 의미가 있습니다.

구문 확장은 오랫동안 수정 자와 데코레이터를 구분 해왔고, 관련된 모든 사람들이 그 구분을 정말 싫어했다고 생각합니다. 따라서 사용자 지정 파생이 약간 특별하게되는 경로를 따라가는 것을 약간 꺼립니다 (설명 된 대안은 매우 특별한 사용자 지정 파생, 아마도 선언 형식 일 수도 있음).

@nrc 음 , 여전히 tokenstream-> tokenstream 일 수 있습니다. 여기서 우리는 처음부터 시작하는 new 메서드를 노출하지 않습니다.

사용자 정의 파생이 실제로 의미가 있도록 필드에 사용자 정의 속성을 가질 수 있어야한다는 데 동의합니다. 그러나 "추가"스타일로이 작업을 수행 할 수있는 방법은 여러 가지가있을 수 있다고 생각합니다. 이것은 물론 논의되어야합니다. 저는 확실히 추가 스타일을 선호합니다. 왜냐하면 파생 매크로가 항목을 변경하지 않고 구성 할 수있는 세계를 선호하기 때문이며 #[structural_eq] 문제를 해결합니다. 이것은 자유 IMO의 적절한 양입니다.

사람들이 그 운명을 좋아하지 않았다면 왜 그런지 물어보고 싶습니다. 왜냐하면 분명히 이전에이 구분을 할 충분한 이유가 있었기 때문입니다.

(제가 제안한 것은 일시적인 해킹 일 뿐이며 장기적인 구성 가능성 문제를 실제로 해결하지는 않습니다.)

내 다양한 ​​라이브러리에는 현재 매개 변수에서 구조체 Bar 를 생성하는 foo!(Bar, parameters...) 와 같은 매크로가 있습니다.

IRC에 대한 토론 중에 #[derive(Foo)] #[params] struct Bar; 대신 foo! 를 구조체의 본문을 생성하는 #[derive(Foo)] 바꾸는 아이디어가있었습니다.

분명히 강력한 주장은 아니지만 구조체가 구축되고 있다는 것이 사용자에게 더 분명하기 때문에 그 아이디어가 정말 마음에 들었습니다.

대신 생성 된 impl에 #[structural_match] 를 배치 할 수 있는지 궁금합니다.

(정말 문제를 해결하지 못함)

Serde와 Diesel은 둘 다 필드에서 사용자 정의 속성을 많이 사용하므로 대체를 허용하기 위해 사용자 정의 파생이 확실히 필요합니다.

그래서 실제로 저는 #[structural_match] 문제에 대해 똑바로 생각하지 않을 수도 있습니다. 결국 사용자 정의 파생은 무엇을 할 수 있습니까?

• 사용자 정의 파생이 #[structural_match] 속성을 잘못 삽입하면 안정성 검사에 실패합니다. 그렇지 않다면 그것은 버그 그 자체로 보입니다! (하지만이 코드가 작동하는 복잡하고 엉뚱한 방식을 감안하면 놀랍지 않습니다.)
• 사용자 정의 파생이 제거하면 아무런 해가 없습니다.

작은 댓글을 많이 쓰고 큰 소리로 생각해서 미안하지만 또 하나의 우려가 있습니다. 사용자 정의 파생이 #[structural_match] 주석을 "위조"할 수는 없지만 ( "매직 스팬"없이 끝날 수 있기 때문에), 아마도 기존 주석의 범위를 망치게 될 것입니다. 파생물이 올바른 순서로 적용되는 것은 안타깝습니다. 기본적으로 @ colin-kiegel이 말한 비 구성 성의 인스턴스이지만 비행 중에 구조체를 수정하려는 시도는 없습니다.

(즉, 안정적인 물건을 사용할 수 있는지 여부를 판단하기 위해 스팬에 의존하기 때문에 스팬 정보를 잃으면 몇 가지 까다로운 문제가 발생할 수 있습니다.)

편집 : 좋아, 다시 읽으면 @sgrif가 이미보고 한 것을 다시 찾았다는 것을

또한 불안정한 구현 세부 사항을 안정적인 코드에 노출하고 있기 때문에 다소 총체적입니다. 이상적으로 안정적인 코드는 #[structural_match] 주석이 존재한다는 사실조차 알지 못합니다.

@nikomatsakis 글쎄, 어떤 식 으로든 매크로가 사용자 정의 파생인지 또는 다른 종류인지에 따라 다른 제약 조건을 적용해야합니다. 이는 함수의 시그니처에 관계없이 별도의 처리 (및 다른 의미 체계)를 의미합니다.

@ colin-kiegel

저는 확실히 추가 스타일을 선호합니다. 왜냐하면 파생 매크로가 항목을 변경하지 않고 구성 할 수있는 세계를 선호하기 때문입니다. 또한 # [structural_eq] 문제를 해결합니다. 이것은 자유 IMO의 적절한 양입니다.

물론 구성 가능성의 용어는 다르지만 변경 매크로를 구성 할 수 있다고 생각합니다. 컴파일러 또는 관례에 의해 시행되는 파생 작업에 대한 사전 및 사후 조건 세트가 분명히 있어야합니다. 비 돌연변이는 우리가 여기서 선택할 수있는 불변의 스펙트럼에서 극단적 인 것처럼 보이며 이미 우리는 그것이 부드럽게 될 수있는 방법에 대해 논의하고 있음을 주목하십시오 (예 : 사용 된 속성 표시). 일반적으로 우리는 가장 간단한 조건을 선호하고 컴파일러에 의해 적용되는 것을 선호합니다. 그러나 이것은 특별히 custom derive가 어떻게 취급되어야하는지에 대한 질문에 다소 포함됩니다.

사람들이 그 운명을 좋아하지 않았다면 왜 그런지 물어보고 싶습니다. 왜냐하면 분명히 이전에이 구분을 할 충분한 이유가 있었기 때문입니다.

나는 그 당시 강한 동기가 있었다고 생각하지 않습니다. 구현하기 쉬웠고 '좋은 생각 같았다'고 생각합니다. 구현을 더 복잡하게 만들고 일반적으로 관련성이없는 매크로 작성자에게 구별을 추가하고 수정 또는 장식 여부를 선택해야하므로 매크로의 유연성이 떨어졌기 때문에 싫어했습니다.

사용자 지정 파생의 장기적인 디자인을 고려하고 올바른 방향으로 가고 있는지 확인하고 싶습니다. 1.1 솔루션의 제약과 가능한 한 빨리하려는 욕구가 이곳의 물을 진흙탕으로 만들고 우리는 더 큰 비전을 보지 못하는 것 같습니다.

나는 어떤 식 으로든 사용자 정의 속성을 지원하는 것이 어려운 요구 사항 인 것처럼 보인다는 점에서 @jimmycuadra 에 동의 합니다. @nikomatsakis 도 옳지 만 #[derive(PartialEq, Eq)] 의 현재 처리가 부차적 이며 안정화해서는 안됩니다. 마지막으로, @mystor 는 사용자 지정 파생 모드가이 마법 속성에 대해 알지 매우 좋은 점 을 가지고 있습니다. 우리는 앞으로 더 많은 것을 추가하고 싶을 것이며, 매크로 1.1이 우리가 그렇게하는 것을 막는 것을 원하지 않습니다.

또한 커스텀 파생의 장기적인 디자인에 대한 @nrc 의 감정을 반영하여,이 많은 부분이 #[derive] 실제로 작동하는 방식으로 귀결 된다고 생각합니다. 임의의 속성을 지원할 때 @nrc 는 수정 자만 있고 데코레이터가없는 것에 대해 좋은 점이 있다고 생각하지만 #[derive] 는 사용자 정의 파생이 새 속성을 정의하지 않고 대신

현재 구현에는 #[derive] 모드의 엄격한 왼쪽에서 오른쪽 확장이 있습니다. 모든 내부 파생 모드는 루프에서 확장되며 사용자 지정 파생 모드에 도달 할 때마다 다시 직렬화하고 확장 한 다음 1 단계로 돌아갑니다. 이는 차례로 컴파일러가 #[derive] 속성을 하나에 대해 _ 여러 번 실행할 수 있음을 의미합니다. 유형 정의 _. 그것은 털이 많은 것으로 이어집니다.

내가 가질 수있는 한 가지 제안은 #[derive] 의 확장 순서를 조정하는 것입니다.

• 첫째, 매크로 1.1의 모든 사용자 지정 파생 속성이 하나씩 확장됩니다. 즉, #[derive(Clone, Foo)] 가있는 경우 먼저 구조체에 #[derive(Clone)] 주석이있는 Foo 파생합니다. #[derive] 지속되면 사용자 정의 내장 특성 Clone 을 파생합니다.
• 둘째, 컴파일러에서 알 수없는 모든 파생 속성이 #[derive_Bar] 속성으로 확장됩니다. 이것은 우리가 언젠가 제거해야하는 하위 호환성 해킹 일 뿐이며 속성을 확장하는 데 사용되는 방법입니다.
• 마지막으로 컴파일러는 알려진 모든 내장 #[derive] 속성을 확장합니다.

이것은 당신이 왼쪽에서 오른쪽,하지만 다시는 것을 기억 확장을 진행하지 않을 것을 놀라운 효과가 #[derive] . 이것은 컴파일러에게 구조체 정의에 대한 최대한의 지식을 제공하고 내장 특성을 확장 할 때 유형의 구조가 절대 변경되지 않는다는 것을 알고 있습니다.

어떻게 들리나요? 여기에서 모든 제약이 해결되었다고 생각합니까?

@nikomatsakis impl 에 속성을 배치하는 전략이 작동 할지 확신 할 수 없습니다. 다른 사용자 지정 파생 모드가 이론상 구조의 레이아웃, 심지어 필드 유형을 변경할 수 있기 때문입니다. 이것은 처음 확장되었을 때 컴파일러의 가정을 위반할 것이라고 생각합니다.

파생물이 처리되는 순서가 Rust 참조 또는 기타를 통해 공식적으로 왼쪽에서 오른쪽으로 선언 된 적이 있습니까? 일반적으로 속성의 순서가 중요합니까? 그렇게 구현 된 것은 우연한 것처럼 들리며 매크로 작성자는 왼쪽에서 오른쪽 순서에 의존해서는 안됩니다. 사용자 지정 처리에 대한 Alex의 제안은 컴파일러에 의해 추가 된 마법 속성을 결코 보지 못하도록 먼저 파생됩니다.

커스텀 파생이 구조체의 레이아웃을 변경할 수 있다는 생각이 마음에 들지 않는다는 점을 덧붙이고 싶습니다. 나는 이것을 안전에 민감한 것에 사용할 수 있기를 원합니다. 예를 들어 rust-gc 사용하는 #[derive(Trace)] 구현을 고려하십시오.

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

다음으로 확장 :

struct Foo {
    a: Gc<i32>,
}

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

그러나 구조체의 필드 변경을 허용하면 Evil 사용자 지정 파생을 정의 할 수 있습니다.

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

다음으로 확장 :

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

그것들을 결합하면 :

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

다음으로 확장 :

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

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

Trace 의 부적절한 구현입니다. rust-gc 와 함께 사용하면 b 가 댕글 링 참조가 될 수 있습니다. 이는 끔찍하게 안전하지 않고 건전하지 않습니다. 이것은 Trace 가 더 이상 유형에서 #[derive] 에게 안전한 것이 아니라는 것을 의미합니다. 이는 매우 불행한 일입니다.

나는 개인적으로 잘 행동하는 #[derive] 이 구조의 레이아웃 / 구성을 수정하지 않을 것이라고 생각하며, 만약 그렇다면 당신은 운이 좋지 않습니다. 사용자 정의 파생이 속성을 삭제하는 기능은 중요하며이를 포기하는 것은 시작이 아닙니다. 추가적으로, 어떤 형태의 화이트리스트를 포함하거나 오늘날 우리가 가지고있는 단순한 인터페이스와 크게 다르지 않은 다른 구현들도 있습니다.

다시 말해, #[derive] 구조를 수정하지 않는 "순수성"이 비용의 가치가 있다고 생각하지 않습니다.

필드를 추가하거나 제거하지 않고 속성을 삭제할 수있는 방법이 있는지 궁금합니다 (예 : 다시 구문 분석 된 구조체에서 필드가 원래 구조체와 동일한 지 확인하고 그렇지 않은 경우 오류 발생) t, 그러나 다른 것이 변경되면 불평하지 않음).

derive가 구조체를 변경하도록 허용하는 것에 대해 나쁜 느낌이 있습니다. @mystor 의 예는 내가 높은 수준에서 구성 가능성 ..에 대해 이야기 할 때 염두에

가능한 한 사람들이 이것을 악용 할 것이라고 생각합니다. 그리고 이로 인해 소비자는 사용자 지정 파생 구현 및 실행 순서에 대한 세부 정보를 추론하게됩니다.

나는 상호 의존성없이 '이봐,이게 뭔지 모르겠지만 다른 하나는 이해한다'라고 말할 수 있으면 좋겠다. 그렇지 않으면 그것은 발가락에 통증이 될 것이고 나는 그것이 일어날 것이라고 믿습니다.

절차 적 매크로가 악의적 인 작업을 수행하는 것은 실제로 악의적 인 작업을 수행하는 크레이트와 다른 점입니까? 모든 상자에는 안되는 작업을 수행하는 안전하지 않은 코드가있을 수 있습니다. 이 경우는 커뮤니티 평판, 소스 직접 검사 등과 같이 직접 작성하지 않은 코드의 신뢰성을 결정하는 방법에 해당하는 것 같습니다.

나는 크레이트가 악의적 인 일을하려고하지 않는다고 생각합니다. 오히려 크레이트가 "영리"하고 깔끔한 트릭을 수행하여 구현을보다 효율적으로 만들거나 할 수 있기 때문에 다른 사용자 지정 파생 구현을 깨뜨릴 수 있기를 바랍니다. 일부 사용자 지정 파생 항목이 구현에서만 사용되는 구조체에 필드를 추가하기 시작하고 Trace와 같은 것을 깨뜨려도 놀라지 않을 것입니다.

@mystor 이론적으로는 관련이있는 것처럼 들리지만 실제로 Rust에서 구조의 모든 필드를 제공해야한다는 것을 기억하십시오. 예를 들어 C ++에서보다 그렇게 조용히 작동 할 가능성이 훨씬 적습니다.

헉헉

내가 가질 수있는 한 가지 제안은 #[derive] 의 확장 순서를 조정하는 것입니다.

이 아이디어가 좋아요. 아마도 문서에서 언급 할 것은 단순히 확장 순서가 "정의되지 않음"이라는 것입니다. 우리는 최근에 PartialEq / Eq를 확장하고 있지만 그렇게해야 할 엄격한 이유는 없습니다.

구조체 정의를 수정하는 파생물에 관해서는 미묘한 소리가 나는 것에 동의하지만 너무 귀찮게하지는 않습니다. 또한 "자동 삽입"필드가 매우 편리 할 수 ​​있다고 생각합니다.하지만 이러한 수정자는 파생 목록에 넣는 것보다 별개의 속성이되는 것이 좋습니다. 주로 사람들이 순서에 의존하는 것을 원하지 않기 때문입니다. 지금 확장의.

추신. 사람들이 확장 순서에 의존 할 수 없도록 상자 해시 또는 이와 유사한 것으로 시드 된 (결정 론적) RNG를 사용하여 사용자의 사용자 지정 파생 확장을 재정렬하는 것을 진지하게 고려할 것입니다. 나는 항상 암시 적 종속성을 방지하기 위해 어떤 맥락에서 이것을하고 싶었지만 결코 기회를 얻지 못했습니다. ;)

편집 : 나는 내 마음을 바꾸었고 더 이상 구조체 변형을 허용하지 않는 이유를 보지 못했지만 컨텍스트에 대한 원래 의견은 다음과 같습니다.

따라서 내 이해에서 다음은 사용자 정의 #[derive] 가 구조체를 변경하도록 허용하는 인수입니다.

• 어떤 경우에는 유용 ​​할 수 있습니다 (예제를 본 적이 없지만 존재한다고 생각합니다)
• 사용 된 속성을 제거 할 수 있기를 원합니다.
• 커스텀 파생 작성자에게 더 많은 권한 제공

사용자 정의 #[derive] 구현에 제한을 추가하기위한 인수 (예 : 구조체의 이름과 구조체의 필드 / 필드 이름이 동일하게 유지되어야 함)는 다음과 같습니다.

• 이것은 사용자 정의 #[derive] 에 의해 생성 된 코드가 건전성을 위해 파생되는 유형의 구조에 의존하도록 허용합니다 (예 : rust-gc의 #[derive(Trace)] . 또는 불건전하며 잠재적으로 미묘한 사용 후 자유 방식)
• 구조체를 통해 전달되는 정보가 적기 때문에 매크로 확장에서 암시 적 종속성의 가능성을 줄입니다.

제 생각에는 unsafe trait impls 또는 안전하지 않은 코드에 의존하는 코드를 생성하는 건전한 사용자 지정 파생 구현을 작성하는 기능이 매우 중요하며, 첫 번째 섹션에서 대부분의 기능을 달성 할 수있는 방법이 있다고 생각합니다 ( 안전한 방법으로 구조체 필드를 추가하는 기능을 제외하고). 어떤 형태의 제약이 없다면 rust-gc와 같은 상자가 안전한 방식으로 구현 될 수있을 것이라고 생각하지 않습니다. 두 가지 아이디어가 있습니다.

아이디어 1

사용자 지정 파생 패스를 실행하기 전에 구조체의 이름과 각 필드의 이름을 읽으십시오. 패스가 완료되고 구조체가 다시 구문 분석되면 구조체의 이름이 동일한 지, 각 필드의 이름 (및 필드 수)이 동일한 지 확인합니다. 그렇지 않은 경우 오류를 발생시키고 빌드를 종료하십시오.

이렇게하면 사용자 지정 파생 플러그인이 의존 할 것으로 예상되는 기본 구조적 속성이 손상되지 않고 더 많은 사운드, 사용자 지정 파생 플러그인이 있음을 의미합니다. 이것은 또한 현재의 접근 방식과 역 호환된다는 장점이 있습니다. 그래서 우리가 미래에 더 좋아 진다고 결정한다면, 우리는 그냥 전환하고 누구의 코드도 깰 수 없습니다. 또한 오늘날처럼 사용되지 않는 속성 케이스를 처리합니다.

아이디어 2

모든 사용자 지정 파생 플러그인에 동일한 입력 TokenStream (프로그램에 작성된 원본 텍스트)을 제공합니다. 결과가 다시 구문 분석 될 때 출력 구조체에 여전히 존재하는 속성을 기록합니다. 모든 출력 토큰 스트림에 속성이있는 경우 사용되지 않은 속성에 대해 불평합니다.

이것은 (개념적으로 모든 사용자 정의 파생 플러그인이 동일한 원래 객체에서 작동하므로) 순서 종속성을 갖는 것이 불가능하며 플러그인의 구조를 망칠 수도 없음을 의미합니다. 이 아이디어는 모든 사용자 정의 파생이 기존 구조체를 기반으로 새 항목 만 생성하는 가장 정상적인 방식으로 작동하도록 보장하기 때문에 좋습니다. 이것은 또한 현재 솔루션을 변환 할 수있는 솔루션으로 쉽게 변환 할 수 있습니다.

TL; DR

요약하면, 변형 구조체를 허용하는 특별한 이점이 무엇인지, 그리고 안전한 #[derive(Trace)] 및 항상 올바른 #[derive(Serialize)] 등을 가능하게 만드는 안전 문제보다 왜 더 중요한지 이해하고 싶습니다. 우리가 mutating structs 경로로 내려 가면 좋은 이유가있을 거라고 확신하지만, 내 Trace custom 파생 이름을 #[derive(unsafe_Trace)] 로 변경하면 매우 슬프게 될 것입니다.

@alexcrichton 의 솔루션이 좋은

@mystor 가 불쾌한 놀라움으로 이어질 수 있다는 좋은 점이 있지만 struct 를 변경할 가능성은 필수 인 것 같습니다. 반면에 절차 적 매크로의 사용 사례, 안전하지 않은 코드 및 보안 문제를 결합한 상자는 드물게 보입니다.

주제에서 벗어남 :이 구현은 매크로가 오류를 정상적으로보고하는 방법을 제공합니까?

커스텀 파생의 확장 순서를 무작위 화하는 @nikomatsakis 의 아이디어가 듭니다 . 그것은 "나쁜"관습이 너무 대중적이되는 것을 막는 데 확실히 도움이 될 것이며 너무 많은 노력을 기울여서는 안됩니다.

@mystor 세 번째 옵션은 모든 파생 항목이 적용된 후 한 번만 이러한 안전 검사를 수행하는 것입니다. 100 % 사운드는 아니지만 (두 개의 파생이 동일한 필드를 추가하고 제거 할 수 있음) 경험적 대책 측면에서 사용자 정의 파생에서 구조체 정의를 변경하려는 시도를 방지하기에 충분해야합니다.

구조체 수정에 대한 우려는 실제로 보이지 않습니다. 필드는 보이지 않게 추가 할 수 없으며 초기화하는 동안주의해야합니다. 그 일이 _ 정말 _ 걱정된다면, 전체 구조체를 쉽게 볼 수 없다면 컴파일에 실패하는 코드를 생성하도록 파생물을 작성할 수 있습니다.

@sgrif는 아마도 _most_ 사례에서 사실 일 것입니다. 그러나 기본 특성이나 동등한 것을 도출하고 사용하는 경우에는 그다지 많지 않습니다.

@sgrif 추신 : 대부분의

구조체에 매크로를 적용하는 일반적인 사용 사례는 확실히 구조체 변경 + 데코레이션의 _combination_입니다. 그러나 나는 일반적인 비율이 "단지 약간의 변경"으로 "많은 장식"이 될 것으로 예상합니다. 가독성과 유연성을 향상시키기 때문에 여기에서 명확한 구분을 갖는 것이 좋습니다.

• 유연성 : 두 가지 모두를 수행하는 두 가지 사용자 정의 파생물, 즉 변경 및 장식을 적용하고 싶다고 가정 해보십시오. 어떻게 주문하든 원하는 결과를 얻지 못할 수 있습니다. 그러나 변경이 다른 메커니즘을 통해 발생하고 나중에 장식이 모두 적용되면보다 제어 가능한 방식으로 여러 변경 및 장식을 결합 할 수있는 유연성이 있습니다.
• 가독성 : 다른 사람의 코드를 읽고 구조체에 10 개의 파생이 적용되고 그중 하나가 구조를 변경하는 경우이를 파악하는 데 더 많은 시간이 필요합니다.

그래서 @mystor 의 주장에서이 부분이 알지만 :

사용자 정의 # [derive]에 의해 생성 된 코드가 건전성을 위해 파생되는 유형의 구조에 의존하도록 허용합니다 (예 : 실제 지원 유형을 확인해야하는 rust-gc에서 # [derive (Trace)] 또는 불건전하며 잠재적으로 미묘한 사용 후 자유 방식)

나는 이것을 유도하는 것이 일을 진행하는 잘못된 방법이라고 생각합니다. 특히, 우리는 아마 일반적인 경우에 구조 정의를 수정할 수있는 기능을 원하십니까 (예, 그것은 투명하지 않습니다,하지만 그래서 뭐). 즉, 나중에 구조체가 변경되지 않는다는 것을 확신 할 수있는 "사운드" Trace 아이디어는 _other_ 방식으로 해결해야 할 수도 있습니다. 데코레이터가 아래에서 위로 적용되는지 고려하십시오.

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

struct 정의가 변경되면 _it_가 컴파일에 실패하는 방식으로 Trace impl을 작성할 수 있다고 생각할 수 있습니다. 예를 들면 :

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

#[mangle] 가 진정으로 악마적인 경우에도 당신의 impl을 망칠 수 있습니다. =) 우리가 여기서 할 수있는 일이 너무 많습니다.

이러한 대화의 관찰자로서 #[derive] 는 impl 블록 만 추가하고 형제 주석 ( #[mangle(Foo, Bar)] 소리 나에게 좋은 😸) 유형의 구조를 _ 변경 _하는 데 전념합니다. #[mangle] 에는 정의 된 평가 순서가있을 수 있습니다.

아직없는 경우 주석간에 정의 된 평가 순서가 있어야합니다.

이에 대한 제 의견이 완화 된 것 같습니다. @nikomatsakis 는 # [derive] 내에서 변형 구조체를 제거하더라도 코드에서 구조체 레이아웃에 대한 가정을 할 수 없다는 좋은 점을 지적합니다. let Foo{ ... } 트릭은 정상적인 경우 레이아웃이 올바른지 확인하는 데 효과적입니다. 그러나 모든 사람이 독립적으로 발견 할 필요가 없도록 어딘가에 문서화해야 할 것입니다.

뿡 빵뀨

• mh .. _custom 데코레이터가 derive_ 전에 적용되어야한다는 추가 규칙이있을 수 있으며 _derives는 item_을 변경할 수 없습니다. 이것은 여전히 ​​일반적으로 파생 역학을 강화 / 정제 할 수 있습니다.

그러나 나중의 변경에 대해 _ 개별적으로 _ 사용자 정의 파생을 강화하는 또 다른 방법이 있다는 것을 알게되어 기쁩니다. :-)

속성이 적용되는 항목의 내부를 수정해야하는 경우에 대해 방금 u.r-l.o 에서 "Pre-implementation feedback for Qt with Rust"스레드를 발견하고이 게시물을 작성했습니다.

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

한 가지 주목할만한 측면은 여기에서 #[derive] (또는 이와 유사한)를 구조체가 아닌 _trait_에 적용하고 그 안에 추가 된 항목은 const 특성 메서드가 될 것임을 제안합니다. .

위에서 제기 한화물 문제와 비슷하지만 확실하지 않습니다.

#[macro_use]
extern crate double;

double 라는 상자에서 절차 매크로 가져 오기. 컴파일 타임에 (실제 Ruest에서와 같이) 런타임 코드를 사용하고 있기 때문에 Racket의 (require (for-syntax ...)) 유사한 단계적으로 증가하는 import 문이 있어야합니다. [라켓 문서는 https://docs.racket-lang.org/reference/require.html# % 28form ._ % 28 % 28lib._racket % 2Fprivate % 2Fbase..rkt % 29._for-meta % 29 % 29, 안타깝게도 올바른 섹션을 연결하는 방법을 알 수 없습니다.]

블로그 게시물 http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/ 는 Template Haskell에서 발생한 단계적 실수를 지적하며 관심이있을 수 있습니다. -나는 Rust에서 같은 실수를하고 싶지 않습니다.

@ Ericson2314 Rust의 차이점은 double 가 이미 특정 단계를 위해 컴파일 된 것입니다 _.
즉, 상자는 macro_rules 와 같이 정의 된 것처럼 매크로 / 수정 자 인터페이스 만 내 보냅니다.
절차 적 매크로와 기본 Rust 항목 (절차 적 매크로를 형성하는)을 모두 내보내는 상자를 만들 수 있다는 것은 흥미로울 것이지만 지금까지는 어떤 능력으로도 제안되지 않은 것 같습니다.

제작되는 상자가 무엇을 어떻게 내보낼 지에 대해 많은 것을 선택할 수 있도록 허용하는 것이 합리적 일 수 있지만, 다른 컴파일 모델을 사용하여 LISP에서 시스템을 도매로 가져 오는 것만으로도 비생산적인 것처럼 보입니다.

그래 @eddyb 나는이 "생성이 다운 스트림에서 어떻게 사용 될지 알고있다"는 방법론에 회의적입니다. 컴파일 모델로 인해 Racket보다 단계가 더 중요하다면 (Racket이 크로스 컴파일 할 수 있는지 확실하지 않습니다), 그래서 마지막 주장을 이해하지 못했습니다.

언어 팀 토론에 지명 : 안정화 계획.

serde 쪽에서는 기존 컴파일러 플러그인 지원을 중단하고 모든 야간 사용자에게 공식적으로 Macros 1.1을 권장하기 전에 남은 문제의 짧은 목록이 있습니다. https://github.com/serde-rs/serde/issues/545. Rust에서 필요한 것은 # 36211을 수정하는 것뿐입니다. 우리가 빠르게 진행하고있는 다른 모든

syntex를 사용하지 않고 rustc_macro를 구현하는 PR이 열려 있으므로 컴파일 시간 https://github.com/serde-rs/serde/pull/548 에 대한 걱정을 멈출 수 있습니다

편집 : 신경 쓰지 마십시오. # 36211은 이전 syntex 구현에만 영향을 미쳤습니다.

나는 이것이 우리가 필요한 모든 것을 할 수 있도록 금요일까지 디젤 항구를 마무리하려고 노력할 것입니다.

@dtolnay 주어진 serde-rs / serde # 548, serde에 대한 나머지 차단기가 있습니까?

@sgrif 굉장합니다, 감사합니다! 그런 다음 (또는 이전에) 만난 나머지 차단제에 대해 여기에 댓글을 달 수 있습니까?

네, 할게요.

2016 년 9 월 27 일 화요일 오후 7:29 Alex Crichton [email protected]
썼다 :

@dtolnay https://github.com/dtolnay 주어진 serde-rs / serde # 548
https://github.com/serde-rs/serde/pull/548 , 남은 항목이 있습니까?
serde에 대한 차단제?

@sgrif https://github.com/sgrif 굉장합니다, 감사합니다! 당신이 그것을 한 후에
(또는 이전에) 남은 차단기로 여기에 댓글을 달 수 있습니까?
만났습니까?

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

뿡 빵뀨

serde-rs / serde # 548에서 serde에 대한 차단제가 남아 있습니까?

아니요, @ oli-obk 또는 @erickt가 오늘 또는 내일 PR을 검토하면 다음 날 모든 것을 푸시하고 Rusoto와 같은 몇 명의 저명한 사용자를 마이그레이션 할 수 있습니다.

@dtolnay 저는 Ruma 에서 serde_macros를 많이 사용하고 있으며 더 많은 눈이 필요한 경우 serde_derive도 테스트하는 데 도움을 드리고 싶습니다.

사실, 저도 diesel_codegen을 사용하므로 Ruma는이 두 라이브러리의 Macros 1.1 버전에 대한 좋은 테스트 장소입니다.

나는 Serde 0.8.10을 발표하여 serde_macros가 매크로 1.1을 위해 더 이상 사용되지

https://github.com/rust-lang/cargo/issues/3132- "cargo doc works"확인란을 추가해 보겠습니다

@dtolnay 완료!

이것이 serde_derive 버그인지 rustc / rustdoc 버그인지 확실하지 않지만 생성 된 문서에서 두 가지 문제를 발견했습니다.

• 사용자 정의 파생을 사용하는 유형의 생성 된 독 스트링 시작 부분에 리터럴 "///"가 나타납니다.
• Deserialize 및 Serialize 는 사용자 정의 파생을 사용하는 유형의 "Trait Implementations"섹션에 표시되지 않습니다.

사용자 정의 파생을 사용하는 유형의 생성 된 독 스트링 시작 부분에 리터럴 "///"가 나타납니다.

이것은 syn 버그였습니다. 나는 0.8.2를 수정하여 cargo update 로 출시했습니다.

나는 두 번째 것에 대해 모른다. @alexcrichton에게 맡길 것이다.

뿡 빵뀨

• Deserialize 및 Serialize 는 사용자 정의 파생을 사용하는 유형의 "Trait Implementations"섹션에 표시되지 않습니다.

그것은 꽤 비린내처럼 들립니다! 이것은 rustdoc의 버그 인 것 같지만 아마도 새로운 버그는 아닐 것입니다. 예를 들어 rustdoc는 Copy 구현에서 이것을 보여주지 않습니다 :

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

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

이 패턴은 serde-derive에서 impl을 생성하는 데 사용됩니다. @dtolnay 도 serde_macros 같은 세대의 형태를 가졌 나요? 문서화 문제를 해결하기 위해 지금 당장 떠나는 것이 쉬울까요?

@jimmycuadra가 그것에 대한 rustdoc 문제를 추적하기 위해 별도의 버그를 열고 싶습니까?

@dtolnay 도 serde_macros 같은 세대의 형태를 가졌 나요?

예.

문서화 문제를 해결하기 위해 지금 당장 떠나는 것이 쉬울까요?

아니요. 제가 아는 한이 두 가지 제약 조건을 모두 충족하는 유일한 솔루션은 다음과 같습니다.

• 상자 루트에없는 serde를 지원해야합니다. 즉 ::serde 아닙니다. 이것은 사람들이 별도의 모듈에서 기능 플래그 뒤에 serde impls을 넣을 때 일반적입니다.
• 주변 모듈의 개인 유형을 사용할 수 있어야합니다.

자세한 내용은 https://github.com/serde-rs/serde/issues/159 를 참조

@dtolnay 아 좋아, 명확히하기 위해 @jimmycuadra 이것은 이전의 회귀가 아닙니다.

업데이트 : 포트는 아직 완료되지 않았지만 거의 완료되었습니다. 내가 이미보고 한 것 외에는 우리가 직면 할 것으로 알고있는 사소한 제한 외에는 문제가 없습니다. "디젤 작동"상자를 확인하는 것이 안전 할 것입니다. 오늘 밤에 발생하지 않는 경우 매크로 1.1에 대한 릴리스가 내일있을 것입니다.

추종자들을 위해 저는 # 36945를 열어서 거의 모든 곳에서 rustc_macro 를 proc_macro 이름을 변경했습니다.이 상자의 이름에 대한 합의가있는 것처럼 보입니다.

rustdoc의 누락 된 특성 구현 (현재 다른 문제에서 추적 중임)이 매크로 1.1에만 국한되지 않은 것 같습니다. 무시해도 안전합니다.

내 mockers 라이브러리를 컴파일러 플러그인에서 매크로 1.1로 이식하려고했는데 "오류 : 사용자 지정 파생 속성이 struct / enum 항목에만 적용될 수 있습니다"라는 메시지가 표시되었습니다. 컴파일러 플러그인을 사용하면 트레이 트에 "derive"를 사용할 수 있습니다 (다소 이상하지만). 내가 여기서 운이 좋지 않습니까?

@kriomant 흥미로운! #[derive] 이 트레이 트에 적용 할 수 있도록 의도 된 적이 있는지 확실하지 않기 때문에 이것이 실제로 커스텀 파생의 버그 일 수 있다고 생각합니다.

지금은 보수적이라고 생각하기 때문에 아직 특성에서 파생되지는 않을 것 같지만 불안정한 기능을 추가 할 수도 있습니다. @ rust-lang / lang의 생각?

@alexcrichton custom_derive의 측면에서 특성과 구조체의 차이점은 무엇입니까?

@KalitaAlexey 없음, 실제 derive 구현 과 일치 인위적인 제한입니다.

@alexcrichton 특성에 대한 지원을 확장 할 수 있습니까?

위에서 언급했듯이 커스텀 파생이 트레이 트에 허용 된 버그 일 가능성이 높으며 이는 RFC에 사양이 지정되지 않았으므로 확장하기 전에 더 많은 논의가 필요합니다. 어쨌든 derive-on-trait에 대한 지원은 첫 번째 패스에서 안정화 될 가능성이 낮지 만 별도의 기능 게이트를 고려할 수 있습니다.

나는 개인적으로 derive-on-trait을 추가하기를 원하지 않습니다. 그것은 그 자체로 파생되기보다는 커스텀 속성 영역의 라인을 따라 훨씬 더 많이 보이기 때문입니다. (예 : 원래 생성 된 #[derive] 의 정신에 위배됨)

사용자 지정 파생이 일반 파생과 똑같은 규칙을 따르는 것을 선호합니다. 우리는 나중에 그것을 변경하고 싶을 수도 있지만 RFC를 받아야한다고 생각합니다. ).

헉헉

지금은 보수적이기 위해 아직 특성 파생을 안정화하지 못할 가능성이 있지만 불안정한 기능을 추가 할 수 있습니다. @ rust-lang / lang의 생각?

👍 나에게서.

좋아, 불안정한 기능은 좋지만 내 라이브러리가 안정적으로 작동하지 않을 것입니다 (코드 생성없이). macro!(…) 구문도 "매크로 1.1"에 포함되지 않습니다. 맞습니까?

proc 매크로 RFC를 다시 검토하고 있으며 매크로 상자가 #[cfg(macro)] 선언해야한다는 계획이있었습니다. 매크로 1.1에는이 기능이 필요하지 않지만 특별한 상자 유형이 필요합니다. 두 가지 메커니즘은 다소 직교합니다. 첫 번째는 컴파일 단계를 설명하고 두 번째는 상자의 종류를 설명합니다. 그러나 그들은 또한 다소 겹칩니다. 후자는 전자를 의미합니다. 전자는 동일한 크레이트에서 proc 매크로와 비 매크로 함수를 선언하도록 확장되는 반면 후자는 그렇지 않습니다.

여기서 변경해야 할 사항이 있는지 확실하지 않습니다. proc 매크로 제안을 이전 버전과의 호환성으로 해킹 할 수 있습니다 (고의적으로 매크로를로드하는 메커니즘과 크레이트 유형을 설명하지 않음). 그러나 안정화 기간 동안 고려해야 할 사항.

@kriomant 맞습니다, 예

@nrc 지금은 실제로 cfg(rustc_macro) 로 정의되어 있습니다 (곧 proc_macro 로 변경 될 예정 임). 우리는 그것을 필요로하지 않습니다.하지만, 컴파일 시간과 런타임에 크레이트에 연결하는 개념 모두에 필요할 것이라고 생각했습니다. 즉, 우리는 proc-macro 크레이트를 두 번 컴파일합니다 : 한 번은 크레이트 유형 proc-macro , 한 번은 크레이트 유형 rlib , 후자는 libsyntax 또는 이와 유사한 것에 링크하지 않습니다. 그.

지금은 _require_하지 않아도 괜찮아 보이지만 나중에 런타임 지원에 옵트 인해야 함을 의미한다고 생각합니다. (크레이트를 두 번 컴파일)

@alexcrichton #[proc_macro_derive] 암시 할 수 있을까요? 동일한 방식으로 #[test] #[cfg(test)] 합니다.
(지금 추가해야한다는 의미는 아닙니다. cfg 추가하는 최악의 경우는 미사용 아이템 경고입니다.)

@eddyb extern crate proc_macro; 어떻습니까? 그것도 깨질 것 같아요.

@mystor 다양한 유형과 impls가있는 일반 상자입니다.

libsyntax 에도 연결되지 않습니다. 즉, 크레이트가 proc_macro 크레이트를 사용하고 크로스 컴파일하려면 구문을 크로스 컴파일해야한다는 의미입니까?

@eddyb yes #[proc_macro_derive] 는 자동으로 무시 될 수 있지만 문제는 이러한 함수가 전 이적으로 도달하는 모든 것을 무시해야한다는 것입니다 (예 : extern crate proc_macro ). "그냥 크레이트"이지만 런타임에 심각한 영향을 미칩니다 (동적 연결, 크로스 컴파일 된 대상에는 사용할 수 없음 등).

테스트에는 #[cfg(test)] 가 있으므로 기본적으로 동일한 목적으로 #[cfg(proc_macro)] 를 제공하는 것이 합리적으로 보입니다.

@alexcrichton _Ideally_, 크레이트에는 내 보낸 것 외에는 아무것도 없으며 동적 링크 또는 이와 유사한 것이 필요하지 않습니다. libstd 있습니다. 그러나 #![no_std] 케이스에서 문제를 일으키는 것을 볼 수 있습니다.

모든 것을 잡으려면 처음부터 더블 컴파일을해야 할 것 같습니다. : dis specified :.

편집 : 잠깐, 내가 무슨 생각을하고 있니? 사용자 정의 상자 유형이 필요하며 이중 컴파일은 _ 일반 _ 상자에 적용되며 _ 또한 _ 절차 적 매크로 / 속성 / 파생 / 등을 _ 내 보냅니다. 그래서 지금은 관련이 없습니다.
그러나 우리는 새로운 상자 유형에 대해 항상 설정된 #[cfg(proc_macro)] 를 도입 할 수 있습니다.

🔔 이 기능은 이 릴리스주기가 끝날 때 안정화 할 목적으로 최종 댓글 기간에 들어갑니다 ! 🔔

이제 안정화를 고려하는 이유는 다음과 같습니다.

• 이 기능의 API 표면은 설계 상 _ 매우 보수적입니다. 동시에 절차 적 매크로에 대한 사실상의 계획과 호환됩니다.
• 이 기능은 Serde를 통해 빠르게 널리 사용되고 있으며, 곧 Diesel이 사용하고 있습니다. 특히 널리 사용되는 것은 주로 사용자 지정 파생의 _client_입니다.
• 이제 FCP에 들어가면 기능이 실제로 안정적으로 출시되기까지 3 개월이 걸리므로 남은 문제를 파악할 수있는 충분한 시간입니다.

이 스레드에 대한 이전 합의에 따라 이름이 proc_macro 로 이동하고 있습니다. 이 릴리스주기의 나머지 부분에 대해 계속해서이 문제와 기타 세부 사항을 자전거 통행 할 수 있습니다.

상자를 두 번 컴파일하는 것은 매우 조잡하게 들립니다. 범위 지정이 제대로 작동하지 않습니다. extern! crate needed_for_my_inline_proc_macros; 와 같은 것이 훨씬 더 좋은 솔루션입니다.

@aturon 뭐, 사람들이 방금 전에 사용하기 시작하지 않았습니까?

@ Ericson2314 그보다 조금 더 길었지만 FCP 코멘트에서 설명했듯이 안정적인 채널로 배송되기까지 _minimum_ 시간은 지금부터 3 개월이며,이 극도로 좁은 인터페이스에 충분하다고 생각합니다.

FCP 자체는 6 주 동안 진행되므로 반드시 안정화를위한 경로에 놓이는 것은 아닙니다. 그러나 적어도 지금 프로세스를 시작하면 그 전에 문제가 발견되지 않았다고 가정하고 3 개월 안에이 기능을 제공 할 기회를 만듭니다.

그래. 나는 3 개월의 부분을 기억했지만, 그 3 개 입에서 FCP의 위치를 ​​잊었다. – 8 월 22 일부터 3 개의 mounths였다. 그때 타이밍은 신경 쓰지 마라.

내가 제기 한 단계적 문제가 proc 매크로 이야기의이 작은 부분에도 영향을 미친다고 생각하므로 해결 된 문제를보고 싶습니다.

@alexcrichton rustc_copy_clone_marker 및 기타 rustc_attrs 가 여전히 우리를 물고 있습니다. https://github.com/serde-rs/serde/issues/577을 참조

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

해결 방법은 주문을 바꾸는 것이지만이 문제를 해결할 수 있는지 확인할 것이라고 생각했습니다.

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

https://github.com/sfackler/rust-postgres-derive 를 매크로 1.1로 이식하는 작업을 마쳤습니다. 상대적으로 고통스럽지 않았지만 다중 파생에서 읽은 속성을 처리하는 것은 큰 고통입니다. Serde는 같은 문제를 겪었지만 동시에 두 파생물을 확장하려면 이상한 논리가 필요합니다. https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-internals/ src / lib.rs # L26

안정화를 막아서는 안되지만 저자 측면에서는 곧 다루어야 할 상대적으로 큰 인체 공학적 문제라고 생각합니다.

quote 0.3.0 을 출시했습니다. 멋진 macro_rules! 스타일 반복을 지원합니다 ( 너지에 대해

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

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

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

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

궁금합니다. 왜 # 가 아닌 $ # $ 입니까?

편집 : 항상 인용 구문이 ${...} 것이라고 생각했지만 몇 년이 지났더라도 ES6 템플릿 리터럴에 너무 집착했을 수 있습니다. \{...} 도 작동하지만 다른 곳에서도 유용합니다.
괄호는 찾기 어려운 것처럼 보이지만 걱정할 필요는 없습니다.

궁금합니다. 왜 # 가 아닌 $ # $ 입니까?

그것은 macro_rules 매크로이고 내가 원하는 것을 할 수 없기 때문에 : smile :. $v 는 단일 토큰으로 일치되며 $v 에서 v 변수를 사용할 방법이 없습니다. 대조적으로 #v 는 두 개의 토큰이므로 개별적으로 일치시키고 ident로 작업을 수행 할 수 있습니다.

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

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

이 모든 것이 macro_rules 에서 완료되기를 기다리십시오.?! Forgot macros 1.1은 잠시 동안 파생 전용이었습니다. 즉, $x 토큰 하나가 IMO의 설계 결함입니다. cc @jseyfried

뿡뿡

@alexcrichton rustc_copy_clone_marker와 다른 rustc_attrs는 여전히 우리를 물고 있습니다. serde-rs / serde # 577을 참조하십시오.

오 이런, 안 좋은 것 같네요! 상단의 목록을 업데이트하겠습니다. @nrc 또는 @jseyfried 우리가 이것을 어떻게 해결할 수 있는지에 대한 생각? 나는 모든 것의 확장 순서에 너무 익숙하지 않지만 #[derive] 속성 하나가 확장 될 때 미래의 모든 속성을 부풀려서 먼저 할 수 있습니까?

뿡뿡

다중 파생에서 읽은 속성을 처리하는 것은 엄청난 고통입니다.

당신이 연결 한 예제를 따랐는지 잘 모르겠습니다. 자세히 설명해 주시겠습니까?

@alexcrichton 예를 들어

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

#[postgres] 속성은 ToSql 및 FromSql 구현이 생성되는 방식을 조정하는 데 사용됩니다. 그렇지 않으면 알려지지 않은 속성이기 때문에 최종 출력 전에 제거해야하지만 ToSql 및 FromSql 구현은 별도로 실행됩니다. 구현을 생성하고 속성을 제거하여 순진한 방식으로 수행하면 두 번째 파생에서 사용자 정의가 누락됩니다.

두 파생 된 impls 모두에 대한 구현을 한 번에 모두 생성하는 동일한 함수로 전달함으로써 지금 바로 serde-derive 및 postgres-derive 해킹. 컴파일러가이를 제거하기 때문에 현재 호출되고있는 #[derive] 를 다시 연결 한 다음 확장되도록 보내야합니다. https://github.com/sfackler/rust-postgres-derive/blob /master/postgres-derive/src/lib.rs#L18

@sfackler 나는 _think_ 동일한 구현 자로부터 파생 된 것이 없을 때만 여분의 속성을 제거함으로써이를 수행 할 수도 있습니다. 당신의 방법이 더 나을 수도 있습니다 _shrug_.

@sfackler 아 좋아, 완벽하게 이해됩니다. 감사!

그래도 그 논리가 깨지기 쉬운 지 궁금합니다. 예를 들어 ToSql 확장하는 경우 FromSql 의 향후 확장은 어떻게 감지됩니까? 위에서 언급 한 @dtolnay 와 같은 #[cfg] 뒤에있을 수 있습니다. 그래서 모든 경우에 탐지가 불가능할 수 있습니까?

@alexcrichton 예, 부서지기 쉬우므로 실제 솔루션이 중요해 보입니다.

#[cfg] 및 #[cfg_attr] 가 파생되기 전에 처리되지 않습니까?

매크로 1.1 api는 문자열에서 작동하므로 세 가지 솔루션 만 상상할 수 있습니다.

1. 그대로두고 매크로 2.0을 기다립니다.
2. 사용자 정의 파생에서 사용되지 않는 속성 허용
3. 사용자 지정 파생이 현재 항목의 특정 화이트리스트에 속성 이름을 푸시하도록 허용하여 매크로 1.1 API를 확장합니다.

각 옵션에는 장단점이 있습니다.
단점 1 : 당분간 취성 해결 방법
단점 2 : 일부 사용하지 않는 속성이 감지되지 않음
단점 3 : 중간 솔루션을위한 더 많은 API 표면

속성을 유지하고 동시에 화이트리스트에 추가하기 위해 #[used(...)] 에 속성을 래핑하는 것을 고려했지만, 꽤 어리 석고 불안정합니다.

헉헉

하나의 #[derive] 속성이 확장되면 미래의 모든 속성을 부 풀릴 수 있습니다.

이 아이디어가 좋아요. #[cfg] s 및 #[cfg_attr] s는 #[derive] s 전에 처리되므로 #[cfg] -guarded #[derive] s는이 접근 방식에 문제가되지 않습니다. (또는 속성 제거 문제에 대한 @sfackler 의 유사한 솔루션).

이 접근 방식은 @sfackler 의 솔루션을 약간 더 간단하게 만들 수 있습니다. 다른 관련 파생물 이 마지막 속성에만있을 수 있기 때문입니다 ( 제안 이 일을 단순화 할 것이라고 생각합니다).

제어 속성 문제에 대한 한 가지 가능성은 syntex와 다소 유사한 post-expansion 콜백을 추가하는 것입니다 : https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/lib. rs # L23 ~ L50

파생 impl은 독립적이고 제어 속성을 제거하지 않을 수 있으며 정리를 위해 모든 확장이 완료된 후 실행되는 패스를 등록 할 수 있습니다.

디젤도 수동으로이 문제를 해결하고 있습니다. https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L101 -L112

@dtolnay 이전 문제 여러 약 #[derive] 속성은해야한다 곧 고정 @jseyfried에 감사를

나는 syn 및 quote 패키지를 사용하여 이것을 가지고 놀았고 정말 긍정적 인 경험을했습니다. 이것은 안정화 될 때 큰 기능이 될 것입니다.

속성 문제는 현재 serde 파생 논리의 다운 스트림 인 내 impl을 물고 있습니다.

파생 코드에서 사용되지 않는 속성을 무시하거나 정규 파생 후 실행되는 늦은 확장이이를 제거하도록 허용하는 것은 나에게 합리적인 해결책처럼 보입니다.

매크로에 원래 토큰 스트림을 변경할 수있는 옵션이 없다면 이상적 일 것입니다. 지금과 매크로 2.0 사이에 야생에서 의존 할 수있는 위험한 기능처럼 보이므로 나중에 제거하기가 어렵습니다.

그래서 제네릭 함수 내부의 유형 경로에 세미콜론이 누락되어 rustc에서 다음과 같은 오류 메시지가 표시되었습니다. 어떤 파생 매크로가 lex 오류를 일으켰는지, 어떤 토큰이 오류를 일으켰는지 등과 같은 더 많은 정보를 제공 할 수 있는지 궁금합니다.

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

LexError에 대한 테스트 케이스를 만들었는데 10 월 13 일 밤마다 발생하는 것으로 보입니다 (rustup에는 업데이트가 없음) https://github.com/keeperofdakeys/proc_macro_derive_test.

@ rust-lang / lang 파생 항목이 주석이 달린 항목을 수정할 수 있는지 여부에 대해 논의해야한다고 생각합니다. 이를 허용하는 간단한 솔루션이지만 사용자의 기대에 어긋나는 것처럼 보이며 상당히 인기가없는 것 같습니다. 나는 여전히 현재의 솔루션을 선호합니다. 단순함이 좋고 제안 된 대안 중 어느 것도 저에게 더 나은 것은 없습니다.

항목을 수정할 수있는 경우 속성을 제어하기위한 몇 가지 솔루션이 필요합니다. 나는 (미래에) 비 파생 속성 매크로가 할 수있는 한, 항목을 수정하는 파생 능력을 유지하는 것에 대해 특별히 강하게 느끼지 않는다고 생각합니다.

누군가 "수정"을 정의해야합니다. 구조체의 멤버를 수정하는 것에 대해 이야기하고 있습니까, 아니면 컴파일러가 알려지지 않은 속성에 대해 불평하지 않도록 속성을 제거하는 것에 대해 이야기하고 있습니까?

구조체의 멤버를 수정하는 것에 대해 이야기하는 경우, 제 생각에 가장 좋은 해결책은 다른 모든 구조체보다 먼저 확장되는 각 구조체에서 하나의 구조체 수정 매크로 만 허용하는 것입니다. 그것은 잘 정의되고 (내 의견으로는) 예상되는 행동을 가질 것입니다.

속성 제거에 대해서만 이야기하는 경우 매크로의 재량에 맡기지 않고 매크로 메커니즘 자체에 속성을 통합하는 방법이있을 것입니다.

파생이 어떻게 작동하는지에 대한 내 직감은 impls를 추가한다는 것입니다. 최종 사용자에게 파생물은 impls를 추가하고 다른 작업을 수행하지 않는 것처럼 보입니다. 특히, 다른 디 라이버에게 중요한 방식으로 구조체를 수정해서는 안되므로 순서에 독립적이어야합니다. 이것이 파생물이 어떻게 작동해야 하는가에 동의합니까, 아니면 파생물이 부착 된 유형에 대해 변환을 수행 할 수 있어야한다고 사람들이 생각합니까?

우리가 그것에 동의한다면, 질문은-우리가 이것을 시행하기 위해 우리가 노출하는 인터페이스를 원합니까, 아니면 이것을 시행 할 작성자를 유도하기 위해 그것을 남겨두고 싶습니까? 여기에는 두 가지 상쇄 문제가있는 것 같습니다.

• derive의 행동 계약을 강제하는 것은 확실히 Rust 솔루션과 비슷해 보입니다.
• serde 및 deisel 을 (를) 이러한 제약 조건으로 작업하는 것은 많은 문제를 야기합니다.

물론 다른 속성이 구조체를 수정하는 방법은 파생, 특히 동작해야하는 방법과 관련이없는 것처럼 보입니다.

주석이 달린 항목을 제거 할 수있는 기능을 통해 현재 시스템이 그렇지 않으면 수행 할 수없는 많은 역할을 채울 수 있습니다.

@sgrif deisel이 파생을 사용하는 방법에 대해 자세히

@withoutboats 그것의 90 %는 당신이 기대하는 것입니다. 우리는 사용자가 제공 한 항목을 만지지 않습니다. 우리는 시스템에 매크로를 해킹하기 위해 주석이 달린 항목을 제거합니다. https://github.com/diesel-rs/diesel/blob/master/diesel/src/macros/macros_from_codegen.rs#L12 -L18. 그 외에도 입력 토큰 스트림에서 아무것도 만지는 유일한 시간은 주석을 제거하는 것입니다. https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L109 -L120

@sgrif 나는 또한 절차 적 뱅 매크로를 얻기 위해 커스텀 파생을 남용했습니다. 개인적으로 매크로 1.1에 절차 적 뱅 매크로 시스템이있어서이 기능을 너무 많이 남용하지 않도록하는 것을 선호합니다. 내가 취할 수있는 좋은 길은 거의 동일한 절차 적 뱅 매크로 스토리가 진행되는 것이라고 생각합니다 (매크로에 전달 된 TokenStream에 존재하지 않는 모든 식별자가 위생으로 숨겨져있는 것과 같이 손이 무겁지만 간단한 위생이있을 수 있습니다.) 그것이 어떻게 생겼는지 정확히 알지 못함) 커스텀 파생을 남용하는 대신 사용하고 커스텀 파생이 그것이있는 구조체를 수정할 수 없도록 만드십시오. 그렇게하면 더 많은 상자를 사용할 수 있고 UX를 개선하며 도출 할 수 있습니다.

그러나 파생을 간단한 매크로로 유지하는 주장을 이해할 수 있습니다.

내 관점은 Macros 1.1의 목표는 가능한 한 많은 요구를 충족 할 수 있도록 최대한 유연하고 유지 관리 부담이 적어 신속하게 안정화되고 매크로 2.0까지 임시 방편 역할을하는 것입니다. 현재 디자인은 제 생각에 그 역할에 매우 잘 맞습니다.

이 역할을 영구적으로 채울 수있는 무언가에 대해 이야기하고 있다면, 나는 그것에 훨씬 더 반대 할 것입니다.

내가 틀렸을 수도 있지만 RFC를 읽은 것은 이것이 영구적으로 파생되는 행동의 기초가 될 것이라는 것입니다. 즉, 앞으로 TokenStream 에 더 많은 메서드가 추가 될 예정이지만 파생 매크로는이 API를 사용하여 현재 주석이 달린 항목에서 임의의 변형을 수행 할 수 있습니다 (이 기능은 deisel의 사용 사례에 필요함). ).

나는 파생물이 이것을 영구적으로 허용하는 것에 대해 꽤 부정적으로 느낍니다. 앞으로 언젠가는 macro_rules 매크로와 함께 더 이상 사용되지 않는 시스템이고 매크로 2.0에서는 더 제한적인 다른 파생 API가 선호된다는 사실을 수락하면 다음과 같습니다. 더 편안합니다.

의도는 데코레이터를 무엇이든 할 수있는 트랜스포머로 지원하는 것 같습니다.
그리고 속성에 입력이없는 간단한 데코레이터로 노출되도록 유도합니다.

@withoutboats : serde는 impls가 생성되는 방식을 수정하기 위해 많은 속성 을 지원합니다. 그래서 우리는 그것들을 처리 한 후에 그것들을 제거하거나 무시할 수있는 능력이 확실히 필요합니다. 그것이 도움이된다면, 우리는 우리가 직접하고자하는 대신 제거해야하는 속성 목록을 컴파일러에 어떻게 든 제공 할 수 있습니다.

@eddyb 나는

@erickt 맞아. 장기적으로 이상적인 솔루션은 해당 속성을 제거하는 책임이있는 deriver 대신 no-op 사용자 지정 속성으로 등록하는 것입니다. 그러나 단기적으로는 불가능합니다.

장기적으로 이상적인 솔루션은 해당 속성을 제거하는 책임이있는 deriver 대신 no-op 사용자 지정 속성으로 등록하는 것입니다. 그러나 단기적으로는 불가능합니다.

단기적으로이를 불가능하게 만드는 컴파일러 내부에 익숙하지 않지만 사용자 지정 파생 플러그인이 제거하려는 사용자 지정 특성 목록을 표시 한 다음 해당 특성에 대한 다른 변환을 거부 할 수 있습니다. 오리지널 아이템?

또한 Diesel은 하나의 이름으로 모든 사용자 정의 속성을 갖는 Serde의 접근 방식을 따르지 않는다는 것을 알 수 있습니다 (예 : Diesel의 #[table_name = "name"] 와 달리 #[serde(rename = "name")] ). 단일 사용자 정의 속성 이름 만 있으면 구현이 단순화됩니까? 목록 대신 등록 되었습니까?

제어 속성 문제에 대한 한 가지 가능성은 syntex와 다소 유사한 post-expansion 콜백을 추가하는 것입니다 : https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/lib. rs # L23 ~ L50

파생 impl은 독립적이고 제어 속성을 제거하지 않을 수 있으며 정리를 위해 모든 확장이 완료된 후 실행되는 패스를 등록 할 수 있습니다.

post-expansion 에서 매크로 1.1에 대한 확장 후 콜백을 구현했습니다. 파생 impl은 제어 속성을 제거하지 않고 독립적 일 수 있으며, 속성을 제거하기 위해 모든 확장이 완료된 후 실행되는 패스를 등록 할 수 있습니다.

오늘 lang 팀 회의에서 수정 / 주문 문제에 대해 논의했습니다. 사용자의 기대에 부응하고 단순함을 원했습니다 (디자인 측면에서 너무 많은 해킹이 겹치지 않고 해독 / 디버그하기 어려운 오류가 발생하지 않음). 대상 데이터의 수정은 놀랍지 만 안전하지 않다는 점에 주목했습니다. 또한 우리는 동기가 좋은 이유가 아니라 그 자체를 위해 순결을 추구 할 수도 있다고 느꼈습니다.

결국 우리는 소스를 수정하지 않는 파생물이 아마도 더 좋을 것이라고 결정했고 그 모델로 변경해야합니다. 이는 FCP 기간 연장을 의미 할 수 있습니다. 스트리핑 속성을 처리하기위한 특별한 메커니즘이 있어야한다고 생각하지 않았습니다. 오히려 컴파일러가 속성을 처리하는 방식은 매크로가 사용하는 속성이 프로그램에 남아 있도록 허용해야합니다. RFC 1755 는이를 고려해야합니다.

이로 인해 일부 사용자 지정 파생 사용자의 안정화가 지연됩니다. 그러나 대부분의 파생물 사용 (특히 사용자를 안정적인 도구 체인에서 벗어나게하는 경우)은 속성을 사용하지 않는다고 생각하므로 예를 들어 대부분의 Serde 사용자는 곧 안정적으로 이동할 수 있습니다. 속성이 필요한 경우 몇주기가 더 오래 걸리지 만 일반적인 경우에는 영향을주지 않습니다 _.

cc @alexcrichton , @dtolnay , @sgrif , @erickt- 생각?

속성은 아마도 당신이 제안하는 것보다 Serde와 Diesel에서 더 일반적으로 사용됩니다. 내 경험상 Serde를 사용하는 모든 프로그램이 속성을 사용한다고 확신합니다. Diesel을 사용하면 확실히 속성을 사용하며, 어떤 데이터베이스 테이블이 구조체에 매핑되는지 diesel_codegen에 알리기 위해 필요하다고 생각합니다.

즉, 사용자 지정 파생 구조체를 변형하지 않는 것이 나에게 올바른 선택 인 것 같습니다. 그것은 단지 모든 것을 단순화하여 많은 이상한 가장자리 케이스를 방지합니다. 신속하게 처리하는 것보다 올바르게 처리하는 것이 더 중요하므로 기능이 조금 더 불안정하게 유지되어야하는 경우에도 문제가 없어 보입니다.

대상 데이터의 수정은 놀랍지 만 안전하지 않다는 점에 주목했습니다.

안전하지 않은 특성을 파생하지 않는 한 안전하지 않습니다.

제 생각에 커스텀 파생의 사용 사례 중 하나는 안전하지 않은 것으로 표시된 트레이 트를 안전한 방식으로 구현하는 것입니다.

내 asn1 상자에는 사소한 용도 이외의 속성도 필요하므로 사용자 지정 속성이 도착할 때까지 효과적으로 기다려야합니다.

사용자 정의 속성 rfc를 두 개로 분할하는 것이 좋은 생각입니까?

1. 일반적으로 커스텀 속성에 대한 표기법 및 네임 스페이스를 제공하는 rfc (안정적인 상태에서 no-op 속성 허용).
2. 정의 방법에 대한 rfc 및 사용자 지정 속성 매크로 실행에 대한 의미 체계

사용자 정의 속성 매크로는 구체화하면 많은 것을 요구하는 것처럼 보입니다. 따라서 rfc를 두 개로 분할하면 사용자 지정 파생 패키지에 대한 안정적인 속성을 더 빨리 제공 할 수 있습니다.

이것은 또한 속성이 이름 공간이 있고 의도적이라는 것을 의미합니다 (예 : 상자에 속성을 사용하려면 외부 상자가 필요함). 동일한 속성 이름을 사용하는 두 개의 사용자 지정 파생 매크로를 방지하는 것이 좋습니다. 여기서 좋은 기대는 속성에 대한 특성이있는 상자의 이름을 사용하는 것입니다.

이 구현이 일반적인 name! 매크로를 포함하지 않는 이유가 있습니까? 일반적인 매크로에 대한 간단한 TokenStream in, TokenStream out은 복잡한 문법에 대한 컴파일 시간이 30 초를 초과하는 pest 에서 매우 유용함을 입증합니다.

@dragostis rfc의 요약을 인용하려면 :

컴파일러에서 오늘날의 절차 적 매크로 시스템의 아주 작은 조각을 추출하여 최종적으로 안정적인 API를 갖도록 사용자 지정 파생 작업과 같은 기본 기능을 얻을 수 있습니다. 이러한 기능이 컴파일러에 유지 관리 부담을주지 않고 "완벽한 매크로 시스템"을위한 충분한 기능을 동시에 제공하지 않도록합니다. 전반적으로 이것은 공식 "매크로 2.0"을 향한 점진적인 단계로 간주되어야합니다.

또는 더 실용적인 용어로, 우리가 지금 구축 한 클로저 시스템처럼 잘 작동하는 절차 적 매크로 시스템을 얻으려면 많은 디자인과 테스트가 필요할 것입니다. serde 및 diesel serde 와 같은 상자에는 적절한 사용자 지정 파생 기능이없는 심각한 사용성 문제가 있으므로 지금 바로 해결하기 위해 임시 방편 조치를 취해 보겠습니다. 이는 가능한 도구와 경험에 도움이됩니다. 절차 적 매크로 시스템. syn 및 quote 상자가 이에 대한 좋은 예입니다.

@keeperofdakeys 네, proc_macro 와 같은 다른 속성을 추가하는 데 부담이 있는지 궁금합니다. pest의 예제는 struct 대한 구문 분석기를 단순히 파생시킬 뿐이며 struct 자체에서 파생되지 않고 {} 사이에 정의 된 간단한 문법에서 파생됩니다. 그래도 죽은 토론을 파헤 치지 않기를 바랍니다!

@dragostis 나는 얼마 전에 내부 에이 가능성을 제기했습니다. https://internals.rust-lang.org/t/pre-rfc-extend-macros-1-1-to-support-foo-style-macros/3921 에서 응답을 읽을 수 있습니다.

@nrc

또한 우리는 동기가 좋은 이유가 아니라 그 자체를 위해 순결을 추구 할 수 있다고 느꼈습니다.

이에 대한 한 가지 참고 사항 : 매개 변수 및 전문화와 같은 어려운 결정을 내려야하는 많은 경우에 "순도"관련 개념을 정적으로 보장하는 것은 어렵거나 불가능합니다. 그러나이 경우에는 실제로 구성을 통해 보증하는 것이 매우 간단하며, 파생 순서의 중요성을 제거하는 것은 사용자에게 매우 강력한 단순화처럼 보입니다.

안정성에 관한 한, 우리는 지금 속성을 무시하기위한 불안정한 메커니즘을 추가하는 것을 고려할 수 있습니다. 이것은 여전히 ​​야간에 사용해야하더라도 실제로는 안정적입니다 (API가 깨지기 쉽지 않다는 점에서). 우리는 이러한 부 채널을 안정화하는 것을 고려할 수 있으며, 사용 가능하면보다 일반적인 메커니즘을 선호하도록 지원을 중단 할 계획입니다. 또는 @keeperofdakeys 의 제안을 고려하고 즉각적인 문제를 해결할 수있는 일반 속성 솔루션을 빠르게 추진할 수 있습니다.

내 관점에서 볼 때, 이러한 우려 중 어느 것도 매크로 1.1이 Serde에서 널리 사용되는 것과 최소한 "사실상"안정된 (즉, 중단되지 않음)을 크게 차단하지 않는 것이 중요합니다.

헉

이 역할을 영구적으로 채울 수있는 무언가에 대해 이야기하고 있다면, 나는 그것에 훨씬 더 반대 할 것입니다.

@withoutboats 를 반향하고 현재 의도는 매크로 2.0을 제공 할 때에도 매크로 1.1 API 표면을 그대로 유지하는 것임을 명확히하고 싶었습니다. 그러나 그것은 우리가 재고 할 수있는 것입니다. 우리는 최종 시스템이 제자리에 놓이면 폐기하려는 의도로 오늘날의 macro_rules와 더 비슷하다고 생각할 수 있습니다.

사용자 정의 파생에 대한 속성 사용에 대한 내 인상은 @jimmycuadra 의 인상 과 비슷 했는데 , 이는 꽤 일반적으로 사용된다는 것입니다. 나는 사용자 정의 속성이 여러 디젤의 사용 사례에 중요하다고 믿습니다 (하지만 내가 틀렸다면 수정하십시오).

그런 의미에서 이러한 속성에 대한 최선의 방법이 무엇인지 100 % 확신하지 못합니다. 매크로 1.1을 안정화하는 것은 부끄러운 일이지만, 처음에는 매크로 1.1의 빠른 안정화 목적을 다소 위배하기 때문에 야간에 많은 수의 사용자를 남겨 두는 것이 부끄러운 일입니다. 다시 말해서, 우리가 매크로 1.1 사용자의 대다수를 _ 실제로 _ 안정적인 Rust로 끌어 들이지 않는다면 안정화 매크로 1.1을 기다릴 수 있다고 생각합니다.

저를 괴롭히는 한 가지 요점은 사용자 정의 속성이 장기적으로 보일 것이라고 생각하고 현재 매크로 1.1 시스템에서이를 합리화 할 것이라는 점입니다. 사용자 지정 속성에 대한 현재 RFC 에서 크레이트는 크레이트 상단에 화이트리스트 속성 네임 스페이스를 선언해야합니다. 즉, 사용자 지정 파생에서 사용자 지정 특성을 사용하는 것은 다른 곳에서 사용자 지정 특성을 사용하는 것과 근본적으로 다릅니다. RFC를 조정하기위한 강제 기능 (예 : serde 크레이트에 연결하면 아마도 serde 속성을 자동으로 화이트리스트에 올릴 수 있음)으로 볼 수 있지만, 이러한 연결 끊김은 인체 공학적 관점에서 "가장 놀라운"관점에서 저를 걱정합니다. ).

전반적으로 저는 개인적으로 매크로 1.1 시스템을 현재 그대로 완벽하게 안정화하여 앞으로 나아갈 수있을 것입니다. 즉, 사용자 지정 파생 확장 함수가 구조체를 수신 한 다음 보존하려는 경우 구조체도 반환해야한다는 사실을 안정화합니다.

나는 rustc-serialize에서 serde _because_ serde의 코드 생성이 제어 속성을 지원하는 것으로 전환하는 경향이 있습니다.

파생 속성 자체에 대한 인수를 지원하도록 매크로 1.1을 확장 할 수 있습니다. 일반적으로 가지고있는 것이 좋은 것처럼 보이며 잠재적으로 단기적으로 제어 속성 부족을 해결하는 것이 남용 될 수 있습니다.

Ditto @jimmycuadra 및 @sfackler , 속성은 @nrc 의 주석이 소리를내는 것보다 중요 합니다. 속성이없는 거의 모든 사용 사례는 rustc-serialize에 의해서도 잘 처리됩니다. 우리가 밤마다 사람들을 없애고 싶다면 rustc-serialize를 선호하는 Serde를 비워 둘 수 있습니다.

여기에서 올바른 움직임에 대한 의견은 아직 없지만, 속성없이 안정화되면 문서 주석을 구문 분석하여 속성을 추출하는 것을 강력히 고려할 것임을 알고 있습니다. 많은 사람들이 다음과 같이 작성할 수 있도록 빌드 스크립트를 처리하고 싶지 않을 것이라고 생각합니다.

#[serde(skip_serializing)]

.. 대신에:

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

토 마카

제 생각에 커스텀 파생의 사용 사례 중 하나는 안전하지 않은 것으로 표시된 트레이 트를 안전한 방식으로 구현하는 것입니다.

이 점에서 여기 내 의견 에 대해 어떻게 생각하십니까? 만족스러운 패턴을 찾았습니다.

한 가지를 명확히하고 싶습니다.

사용자 지정 속성을 제거하는 것이 사람들이 사용자 지정 파생으로 수행 하는 주요 작업입니까?

내가 할 수있는 몇 가지 해킹이 알고 foo! 방법 중앙 그 사용 사례가 있습니다 - 유형 (예, @sgrif 디젤 이러한 사용 사례를 언급, 내가 @tomaka 너무 하나를 언급 한 생각)의 맥락에서 확장 ?

내가 묻는 이유는 이것이다 : 파생 메커니즘이 추가 impls 목록 만 돌려주는 이점을 봅니다. 특히 유형 선언 자체의 범위가 정확하다는 것을 의미합니다. 해당 유형의 컨텍스트에서 화이트리스트에 속성 이름 목록을 제공 할 수있는 빠르고 더러운 API를 컨텍스트에 추가하는 것은 속성에 대한 충분히 쉬운 수정처럼 보이며 항상 사용을 중단 할 수 있습니다.

그러나 우리가 더 많은 유스 케이스를 활성화하고 싶다면 (솔직히 그 유스 케이스가 좀 더 ... 놀랍게도 파생에서 기대하는 것을 생각할 때) 작동하지 않습니다. 이고 계획 (쓰기 도출하기 위해 더 나은 방법 대신 미래에 "생의 바이트에서"API를 비추천으로 모든 후, 우리가 정말 사람들이 기대하지 않는 경우에, 나는 아마 안정과 벌금을 것 어쨌든 원시 바이트를 사용하는 것이 맞습니까?하지만 토큰 스트림을 사용합니까?) API에 약간 더 복잡한 이름을 지정할 수 있습니다 =)

@nikomatsakis 주된 필요는 속성을 제거하는 것이 아니라 무시하는 것입니다. 나는 그들을 무시하는 심각한 단점을 알지 못합니다. 예를 들어, 주요 속성에 대한 추가 매개 변수를 통해 파생 함수에 대한 화이트리스트를 제공하는 것은 절차 적 매크로 해킹이 아닌 실제 파생되는 모든 실제 요구 사항에 충분해야합니다.

그래, 나는 이것에 대한 두 가지 접근 방식 사이에서 갈등을 겪고 있으며, 둘 다 분명한 단점이 있습니다.

1. "단순 파생"접근 방식-추가 항목 만 생성하도록 API를 조정하여 사용자가 파생의 일부로 사용자 정의 속성을 사용하는 것을 여전히 불안정하게 만들고, 디젤 및 기타 상자가 임의의 절차 적 매크로를 얻기 위해 점프하는 구멍을 닫습니다.
2. "계획된 노후화"접근 방식-이름 지정에 대해 언급 한 Niko와 같은 작은 조정을 통해 API를있는 그대로 안정화하고 언젠가는 사용을 중단 할 의도입니다. 이를 위해서는 모든 사용자 지정 파생 작성자가 언젠가 코드를 다시 작성해야하며 중간 기간 동안 놀라운 동작이 발생할 가능성이 있습니다.

편집 : 그러나 @eddyb 의 화이트리스트도 유망하게 들립니다.

내 말은 @nrc 가 (IIRC가 사용자 크레이트의 화이트리스트에 대해 이야기하고 있지만) 훨씬 다른 것을 제안하는 것과는 다릅니다. 토큰 스트림 만 있으면 "사용 된 속성 표시"에 대해 이야기하는 것은 어리 석습니다.

내가 rust-cpp에서 매크로 1.1 시스템을 악용해온 임의의 절차 적 매크로는 단순히 impls를 추가하고 속성을 무시하는 기능을 제공하는 대체 접근 방식으로 완전히 가능할 것입니다.

속성을 무시할 수있는 능력이 필수적이라고 생각하지만 그 외에는 그 지점을 넘어서 구조체를 수정할 수 없어도 괜찮습니다.

@sgrif 가 deisel에서 어떤 형태의 해킹을 사용하고 있는지 잘 모르겠습니다. 구조 자체를 수정할 수없고 대신 추가 항목 만 추가 할 수있는 세상에서는 _ 가능하지 않습니다.

@sfackler가 제안한대로 사용자 지정 파생이 인수를 받도록 허용하는 것은 사용자 지정 특성에 대한 결정을 연기하는 동안 모든 사람이 필요한 기능을 얻을 수있는 방법이 될 수 있습니다. 보기에 좋거나 가독성이 좋지는 않지만 작업을 완료 할 수 있습니다. 예 :

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

이 양식은 나중에 결정이 내려지면 사용자 정의 속성을 위해 더 이상 사용되지 않을 수 있습니다.

serde와 내 상자 모두 필드 / 변형 속성이 필요합니다. 파생 인수로 이것을 모방하려는 것은별로 의미가 없으며 속성이 필요합니다.

이를 안정화하기 위해 어떤 결정을 내리 든, 사용자 정의 파생 매크로 사용자가 매크로 2.0 파생 API로 전환 할 때 코드를 수정할 필요가 없다면 좋을 것입니다 (분명히 사용자 정의 파생 매크로 작성자가 수행 할 것입니다). 가장 현명한 결정은 컴파일러에게 파생을 위해 제거 할 속성 목록을 제공하는 것 같습니다. 결정적으로, 그것들은 _all_ 파생 매크로가 실행 된 후에 만 ​​제거됩니다. Serde, diesel 및 내 상자는 모두 여러 파생 매크로에 대해 동일한 속성을 요구하는 문제가 있습니다.

스트리핑 동작을 사용하면 나머지가 실행 된 후 속성을 제거하기 위해 @dtolnay 가 다른 파생 매크로를 추가하기 위해 만든 확장 후 크레이트가 필요하지 않습니다.

FWIW 이러한 속성을 제거하는 유일한 이유는 HIR을 더 얇게 유지하는 것입니다. 다른 모든 문제에 대해서는 사용 된 것으로 표시하기 만하면됩니다.

사용자 지정 속성을 제거하는 것이 사람들이 사용자 지정 파생으로 수행하는 주요 작업입니까?

나는 foo를 할 몇 가지 해킹이 있다는 것을 알고 있습니다! 유형의 맥락에서 확장 (예를 들어, @sgrif 디젤 이러한 사용 사례를 언급, 나는 @tomaka 너무 하나를 언급 한 생각) - 어떻게 중앙 그 사용 사례는?

커스텀 파생이 구조체를 수정할 수 없다는 사실에 전적으로 동의합니다.

저는 안정적인 Rust에 플러그인이 없다는 점에 대해 자주 불평합니다. 그래서 커스텀 파생을 보았을 때 플러그인을 가질 기회로 사용했습니다. 그러나 나는 커스텀 파생이 그들이 설계되지 않은 것을 지원해야한다고 분명히 주장하지 않을 것입니다.

최근 야간에 회귀가 발생한 것 같습니다. 오류 받기

Queryable 은 파생 모드입니다.

예제를 컴파일 할 때.

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

@sgrif # 37198로 인해 다른 매크로와 동일한 네임 스페이스를 사용하도록 사용자 정의 파생이 변경되었습니다 ( bang!() 매크로, #[attribute] 매크로 및 #[derive(custom)] 매크로 모두 공유 동일한 네임 스페이스).

이 예제에서 #[macro_use] extern crate diesel; 는 Queryable 라는 이름의 bang 매크로를 가져오고 #[macro_use] extern crate diesel_codegen; 는 이름이 Queryable 인 사용자 지정 파생 매크로를 가져옵니다.이 매크로는 자동으로 bang 매크로를 덮어 씁니다. - #[macro_use] 조용히 덮어 쓰기는 적합하지 않습니다,하지만 우리가 통근 상자에서 매크로를 가져올 수 있습니다 일단 문제가되지 않을 것입니다 use 대신 #[macro_use] 곧!).

나는 오류가 쾅 매크로 호출에 의한 것으로 판단 Queryable!(); 사용자 정의 파생의 확장에서, 어떤에서 사용자 지정 도출 할 결의 diesel_codegen 에서 대신 강타 매크로 diesel .

@jseyfried 세 가지 "종류"의 매크로 모두에 단일 네임 스페이스를 사용하는 이유는 무엇입니까? 속성과 매크로를 동일한 네임 스페이스를 차지하는 것으로 취급하는 것이 더 이상 말이되지 않는 것 같습니다. 함수와 유형을 동일한 네임 스페이스를 차지하는 것으로 처리하는 것이 더 이상 의미가 없습니다 (매크로를 더 적게 파생).

@withoutboats 나는 그것이 잘못된 비유라고 생각한다. 나는 다른 종류의 매크로가 다른 종류의 값이나 타입이하는 것과 같은 방식으로 네임 스페이스를 공유한다고 생각하는 것을 선호한다 (예 : 함수와 const). 네임 스페이스를 사용하는 데는 복잡성 비용이 있으며 적은 수의 네임 스페이스가 더 좋다고 생각하므로 왜 다른 네임 스페이스가 필요한가요? 역 호환을 위해서는 매크로가 함수 및 유형과 다른 네임 스페이스에 있어야합니다.

진짜 문제는 use 를 사용하여 매크로를 선택적으로 가져 오거나 이름을 바꿀 수 없다는 것입니다. 따라서 상자 사용자는 매크로 이름 충돌을 피할 수 없습니다. 동시에 ProcMacro 크레이트를 가져 와서 로컬 매크로 이름과 충돌 할 것으로 기대하지는 않습니다. 파생 매크로가 derive_ 시작한다고 생각했습니다.

네임 스페이스를 사용하는 데는 복잡성 비용이 있으며 적은 수의 네임 스페이스가 더 좋다고 생각하므로 왜 다른 네임 스페이스가 필요한가요?

항목이 서로 모호 할 수있는 경우에만 네임 스페이스를 공유해야한다고 생각합니다. const와 fns는 모두 식 컨텍스트에서 ID로 사용되므로 동일한 네임 스페이스에 있습니다. 유형 및 특성은 특성 개체에 대한 구문 때문에 동일한 네임 스페이스에 있습니다.

이 세 가지 종류의 매크로는 모두 고유 한 방식으로 호출됩니다. 호출에 모호함이있을 수 없기 때문에 네임 스페이스를 공유해야한다는 것이 저에게 이치에 맞지 않습니다.

구현 복잡성 비용이 있지만 이러한 이름을 별도로 지정하여 _use_ 복잡성에 상당한 비용이 든다고 생각하지 않습니다. 언어 기능의 복잡성 비용에 대해 생각할 때 일반적으로 사용 복잡성에 대해 생각합니다.

_all_ 항목이 주요 변경 사항이 아니라면 동일한 네임 스페이스에 있어야한다고 말씀 하시겠습니까? 당신의 사고 과정을 명확히하려고 노력합니다.

조금 더 생각해 보면, 모든 항목이 들어있는 네임 스페이스가 1 개만 있어야한다고해도 괜찮을 것입니다. 전체 "실제 생성자"패턴은 IMO를 다소 헷갈 리게합니다.하지만 그것은 Rust가 비 매크로 항목에 대해 내린 결정이 아니기 때문에 매크로 항목이 다른 네임 스페이스를 차지하는 것이 더 일관적이고 기대되는 것처럼 보입니다.

진짜 문제는 매크로를 선택적으로 가져 오거나 이름을 바꾸는 데 사용할 수 없다는 것입니다.

매크로 2.0을 사용할 수 있습니다. 여기 모델은 기본적으로 스탑 갭 해킹입니다.

파생 매크로가 derive_로 시작한다고 생각했습니다.

그것은 오래된 커스텀 파생 시스템이었고, 나는 매크로 1.1이 이것을 수행한다고 생각하지 않습니다.

구현 복잡성 비용이 있지만 사용 복잡성에 상당한 비용이 든다고 생각하지 않습니다.

사용을 정의하는 데에는 비용이 듭니다. 특히 도구의 경우 삶을 더 어렵게 만듭니다 (그다지 논쟁 할 수는 없지만). 또한 언어 복잡성만큼 중요한 것은 구현 복잡성이 그리 크지 않다고 생각합니다 (네임 스페이스가 컴파일러를 확실히 복잡하게 만들지 만, 이것이 그렇게 중요하지 않다는 데 동의합니다). 위생 및 그림자와 같은 것에 영향을 미치고 더 복잡하게 만듭니다.

주요 변경 사항이 아니라면 모든 항목이 동일한 네임 스페이스에 있어야한다고 말씀 하시겠습니까? 당신의 사고 과정을 명확히하려고 노력합니다.

나는 그렇게 멀리 가지 않을 것입니다. 값과 유형이 분리되어 있으면 이점이 있다고 생각하지만 확실히 단일 네임 스페이스를 가진 언어는 여러면에서 작업하는 것이 훨씬 더 좋을 것입니다.

하지만 그것은 Rust가 매크로가 아닌 항목에 대해 내린 결정이 아닙니다.

대위법 : 모듈과 필드는 값 네임 스페이스에 있지만 사용할 수있는 위치는 다른 값을 사용할 수있는 위치와 다릅니다.

안녕하세요.

진짜 문제는 use 를 사용하여 매크로를 선택적으로 가져 오거나 이름을 바꿀 수 없다는 것입니다.

곧 기능 게이트 뒤에서 use 매크로를 extern crate s에서 사용할 수 있습니다 (~ 1 주), cf https://github.com/rust-lang/rfcs/pull/1561 그리고 # 35896. 사용자 정의 파생 상자에서 use 매크로를 사용자 정의 파생 상자와 함께 안정화하기로 결정할 수 있습니다.

파생 매크로가 derive_ 시작한다고 생각했습니다.

이것은 구식 커스텀 파생물에 해당됩니다. 매크로 1.1 사용자 정의 파생을 사용하면 #[derive(Serialize)] (예 :)에서 Serialize 가 사용자 정의 파생 매크로로 해석 될 것으로 예상합니다.

안녕하세요.

세 가지 "종류"의 매크로 모두에 단일 네임 스페이스를 사용하는 이유는 무엇입니까?

• 우선 순위 : bang 매크로와 속성 매크로는 오랫동안 네임 스페이스를 공유해 왔으므로 변경 될 때까지 사용자 지정 파생도 해당 네임 스페이스를 공유해야한다고 생각합니다.
• 역 호환성 : 단일 매크로 네임 스페이스로 시작하면 역 호환 적으로 분할 할 수 있습니다. 여러 매크로 네임 스페이스로 시작하면 영원히 고정됩니다.
• 단순성 : 각 매크로 "종류"에 자체 네임 스페이스가있는 경우 총 5 개의 네임 스페이스가 있습니다. 따라서 https://github.com/rust-lang/rfcs/pull/1561 착륙 후 use foo::bar; 는 bar (값, 유형, bang 매크로)라는 이름의 _5 개의 개별 항목 _을 가져올 수 있습니다. 예를 들어 사용자 지정 파생 매크로가 아닌 bang 매크로를 다시 내보내거나 사용자 지정 파생 매크로를 baz 으로 가져 오는 간단한 방법은 없습니다.

역 호환성 : 단일 매크로 네임 스페이스로 시작하면 역 호환 적으로 분할 할 수 있습니다. 여러 매크로 네임 스페이스로 시작하면 영원히 고정됩니다.

특히 1.1이 임시 방편이되어야하기 때문에 이것은 설득력이 있습니다. : +1 :

PartialEq! 같은 macro_rules 매크로를 가진 사람을 위해이 코드가 중단됩니까?

아니요, PartialEq 은 (는) 사용자 지정 파생이 아니기 때문에 오늘날 매크로 네임 스페이스에 정의되어 있지 않습니다.
#[derive(Foo)] 는 사용자 정의 파생을 찾기 전에 Foo 가 "내장 파생"( PartialEq , Copy 등)인지 먼저 확인합니다. Foo 매크로 네임 스페이스에 있습니다. 내장 기능은 derive 정의에 하드 코딩됩니다.

즉, 우리가 결국 PartialEq 내장 대신 전주곡에서 사용자 정의 파생으로 만들기로 결정하면 설명한대로 코드를 깨뜨릴 수 있으므로 지금 이에 대한 미래를 증명하는 것이 좋습니다.

속성 문제에 대한 제안 (파생 매크로가 선언 된 항목을 수정할 수없고 장식 만하는 모델에서 작업한다고 가정) :

• 배후에서 커스텀 파생 매크로는 현재 MultiItemModifier 트레이 트를 구현합니다. 매크로 2.0이 계속해서 특성을 구현하고이 특성을 메커니즘의 확장성에 사용하는 것이 계획입니다. 매크로 인 주석이 달린 함수가이 특성을 구현합니다. 플러그인 등록 기관을 사용하지 않지만 이는 본질적으로 설탕 제거입니다.
• 매크로 1.1 커스텀 파생을 위해 특별히 CustomDerive 트레이 트를 분리해야합니다. 일반적인 경우, 매크로 작성자는이를 볼 수 없습니다. 그러나 그들은 함수에 속성을 사용하는 대신 특성을 직접 구현할 수있는 옵션이 있습니다. (나는 우리가 impl에서 속성을 재사용 할 것으로 예상합니다. 아마도이 등록 메커니즘을 논의해야 할 것입니다).
• 우리는 추가 declare_attributes 에 기능을 CustomDerive 반환 Vec<String> . 빈 vec를 반환하는 기본 impl이 있습니다.
• 매크로 작성자가이 메서드를 구현하면 반환 된 문자열 중 하나로 정확히 명명 된 모든 속성이 매크로에 속한 것으로 간주됩니다. 이러한 속성은 매크로처럼 조회되지 않으며 맞춤 속성 lint를 트리거하지 않습니다. 속성은 파생 확장에 의해 코드에 남아 있지만 사용 된 것으로 표시됩니다. 파생 확장의 영향을받지 않는 이러한 속성은 여전히 ​​사용되지 않는 속성 lint를 트리거합니다 (맞춤 속성 lint는 아님).
• 앞으로 사용자 정의 파생을 포함한 매크로가 사용할 수있는 범위 속성을 도입 할 수 있습니다. 이러한 속성은 declare_attributes _ 추가 _되며이 메커니즘은 더 이상 사용되지 않습니다.
• 대안 : declare_attributes 반환 된 문자열은 속성의 경로 접두사로 확인됩니다. 예를 들어 declare_attributes vec!["foo::bar"] 반환 한 경우 #[foo::bar::baz] 및 #[foo::bar::qux] 이 허용됩니다.

생각? cc @alexcrichton @jseyfried @dtolnay @sgrif @erickt @ rust-lang / lang

@nrc 가 #[cfg(..)] 와 같은 _used_ 속성을 실수로 또는 고의로 비활성화 할 수 있습니까? 그리고 그것은 바뀔 수 있습니까?

@nrc 불행히도 이러한 제약 조건을 고려할 때 구현이 어떻게 생겼는지 알 수 없으므로 작동하는지 여부를 완전히 확신 할 수 없습니다.

트레이 트의 인스턴스가 생성되는 위치에 있기 때문에 트레이 트와 트레이 트 객체가 작동하는지 여부에 대해 다소 회의적이라고합니다.

@nrc 왜 이것이 필수적이어야하고 파생 확장기 기능을 지정하는 속성의 목록이 될 수없는 이유는 무엇입니까? 예 : #[proc_macro_derive(Serialize, uses_attrs(serde_foo, serde_bar))] 또는 일부.

@ colin-kiegel 파생 응용 프로그램의 범위에만 적용 할 수 있다고 생각합니다.이 경우 매크로 확장 전에 cfgs를 적용 할 수 있다고 생각하지만 다른 속성을 비활성화하는 것은 예상되는 동작 일 것입니다 (이것은 변경되었지만 기억할 수 없습니다). 이전 대 이후).

헉헉

트레이 트의 인스턴스가 생성되는 위치에 있기 때문에 트레이 트와 트레이 트 객체가 작동하는지 여부에 대해 다소 회의적이라고합니다.

흠, 좋은 지적입니다. 매크로 2.0에 대해이 문제를 해결해야합니다.

@eddyb 이것은 좋은 생각이며 아마도 단기적으로하기가 더 쉬울 것입니다. 명령형 접근 방식을 선호하는 이유는 이것이 일반적인 확장 성 메커니즘이며 유지하고 싶은 반면 속성에 항목을 추가하는 것은 너무 잘 확장되지 않으며 영원히 고정되고 싶지 않은 것이 아닐 수도 있기 때문입니다. . 반면에 지금은 확실히하기가 더 쉽고 주위를 맴도는 것이 나쁘지 않은 것 같으므로 더 나은 방법이라고 생각합니다.

잡히기-나는 나라를 떠났고 아프다. 모든 종류의 매크로가 동일한 네임 스페이스를 차지하는 것이 합리적이지 않다고 생각하므로 https://github.com/rust-lang/rust/pull/37198 을 다시 방문하고 싶습니다. 최소한 사용자 지정 파생 매크로가 해당 네임 스페이스에 derive_Foo 또는 이와 유사한 것으로 예상됩니다. 표준 라이브러리에서도 동일한 이름을 사용하는 여러 유형의 매크로에 대한 사용 사례가 있습니다 (예 : #[cfg] 및 cfg! )

또한 공유 네임 스페이스가 조금 어색하다고 생각합니다. 최종 사용자의 관점에서 보면 일종의 상호 교환 성, 모호성 또는 흥미로운 일이있는 것처럼 보일 수 있습니다. 나는 이와 같은 '무작위'제한이 Rust를 언어로 이해하는 것을 조금 더 어렵게 만들 수 있다고 생각합니다 ..

하지만 아마 세상의 끝은 아닐 것 같습니다. 다른 네임 스페이스는 앞으로도 많이 중단되지 않고 도입 될 수있는 것으로 보입니다.

@sgrif @ colin-kiegel https://github.com/rust-lang/rust/issues/35900#issuecomment -256247659에서 단일 매크로 네임 스페이스에 대한 근거를 설명했습니다.

모든 종류의 매크로가 동일한 네임 스페이스를 차지하는 것은 의미가 없다고 생각합니다.

명확하게 말하면, bang 매크로와 속성 매크로는 항상 동일한 네임 스페이스를 차지했습니다. # 37198 방금 이동 한 사용자 지정 파생 항목이이 네임 스페이스로 들어갑니다.

표준 라이브러리에서도 동일한 이름을 사용하는 여러 유형의 매크로에 대한 사용 사례가 있습니다 (예 : #[cfg] 및 cfg! )

또는 cfg 는 bang 호출 또는 속성 호출을 통해 사용할 수있는 단일 매크로로 볼 수 있습니다 (현재 사용자가 bang 또는 속성을 통해 호출 할 수있는 매크로를 정의하는 것은 불가능하지만, 매크로 2.0에서 허용하기로 결정할 수 있습니다.)

최종 사용자의 관점에서 보면 일종의 호환성이있는 것처럼 보일 수 있습니다.

두 매크로가 충돌 할 때 명확한 오류 메시지로 개선 될 수 있다고 생각합니다 (오늘의 메시지를 개선하기 위해 노력하겠습니다).

다른 네임 스페이스는 많은 부분을 중단하지 않고 앞으로도 계속 도입 될 수 있습니다.

매크로 네임 스페이스를 분할하는 것이 이전 버전과 완전히 호환된다고 생각합니다 (내가 틀렸다면 수정). 이것이 오늘 단일 매크로 네임 스페이스를 유지하는 주된 동기입니다. 우리는 매크로 1.1이 가능한 한 미래에 호환되기를 바랍니다.

마지막으로, bang / attribute 매크로 대 사용자 지정 파생 매크로 충돌은 실제로는 드물다고 생각합니다. bang / attribute 매크로는 일반적으로 소문자이고 사용자 지정 파생은 일반적으로 대문자이기 때문입니다. 즉, 이러한 명명 규칙을 따를 때 사용자 지정 파생에는 이미 자체 네임 스페이스가 있습니다.

파손 (https://github.com/diesel-rs/diesel/issues/485)은 Queryable! { struct S; } 및 #[derive(Queryable)] struct S; 지원으로 인해 발생한 것 같습니다. 커스텀 파생이 안정되면 Queryable! { struct S; } 을 지원할 필요가 없으므로 더 이상 문제가되지 않습니다.

그동안 diesel 업데이트하여

• Queryable! 는 #[macro_use] extern crate diesel_codegen; 없이도 계속 지원됩니다.
• #[derive(Queryable)] 있지만 Queryable! , 지원됩니다 #[macro_use] extern crate diesel_codegen; .

토론을 위해 IRC에서 저를 자유롭게 핑하십시오. PR을 작성해 주시면 감사하겠습니다.

트윗 담아 가기

트레이 트의 인스턴스가 생성되는 위치에 있기 때문에 트레이 트와 트레이 트 객체가 작동하는지 여부에 대해 다소 회의적이라고합니다.

@eddyb의 의견에 동의합니다. 편의성과 편의성을 위해 속성을 처리하는 것이면 속성을 확장하면됩니다.

그러나 우리가 좀 더 유연한 확장 시스템을 원했다면 나는 우리가 traits를 사용할 것이라고 생각했지만, 그 traits는 Self 참조하지 않는 메소드 모음으로 정의 될 것입니다.

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

그런 다음 struct my_annotation_type; 와 같은 더미 유형 (속성과 같은 이름을 공유합니까?)에서 구현하고 특성 분석을 사용하여 <my_annotation as CustomDerive>::foo 와 같은 관련 함수를 추출합니다 (아마도 메타 데이터를 작성할 때). 요점은 my_annotation 의 인스턴스를 만들거나 필요로하지 않는다는 것입니다. 이는 관련 함수를 묶는 그룹화 메커니즘 일뿐입니다.

확실히 가장 우아한 것은 아니지만 더 좋은 방법이 확실하지 않습니까? 나는 우아함이 우리가 속성 기능으로 시작하고 싶었던 이유라고 생각합니다. =)

네임 스페이스와 관련하여 @sgrif 는 #[cfg] 및 cfg! 예제에서 좋은 사례입니다. 나는 확실히 하나가 원하는 상상할 수 #[derive(SomeTrait)] 과도 같은 몇 가지 매크로가 SomeTrait! { ... } 무언가를 있음을 .... =) 그러나 @jseyfried 는 또한 우리가 한계에 부딪히지 않는 한 _ 이미 _.

나는 기본적으로 더 적은 수의 네임 스페이스를 선호하는 경향이 있는데, 대부분 값 / 유형 네임 스페이스 분할이 이제 우리에게 가져 온다고 생각하는 고통 때문입니다. 즉, 알려진 문제점의 대부분이 여기에 적용되지 않는다고 생각합니다.

• 유형 / 값 분할은 use foo::bar 라는 모듈을 bar 으로 가져 오거나 가져 오지 않을 수 있으므로 bar::baz 와 같은 이름 확인과 관련이있을 수도 있고 그렇지 않을 수도 있기 때문에 이름 확인에 어려움이 있습니다.
• 유형 / 값 분할은 상수에 대한 제네릭의 경우 일종의 고통이지만 유형과 값 사이의 구문 분할 때문에 고통이 발생하기도합니다.

하지만 대체로 우리가 다리를 건 넜기 때문에 자체 네임 스페이스에서 "사용자 지정 파생"을 사용하는 것이 특정 문제를 가져 오는지 확실하지 않습니다.

derive_ 접두사를 생성 된 매크로에 추가하여 가상 네임 스페이스로 만들 수 있습니다. 우리가 그 변화를 원한다면 지금이 바로 그때가 될 것입니다.

@keeperofdakeys 사용자 지정 파생 이름을 derive_* 지정하기로 결정한 사용자 지정 파생 작성자와 동일하지 않습니까? 어쨌든 derive_* 이름은 최종 사용자에게 너무 추한 것 같습니다.

뿡 빵뀨

하지만 대체로 우리가 다리를 건 넜기 때문에 자체 네임 스페이스에서 "사용자 지정 파생"을 사용하는 것이 특정 문제를 가져 오는지 확실하지 않습니다.

가져 오기 확인 알고리즘은 임의의 많은 네임 스페이스를 처리 할 수 ​​있지만 각 네임 스페이스에 대해 잠재적으로 사소한 양의 작업을 수행합니다. 특히 각 가져 오기 I 및 사용되지 않은 각 네임 스페이스 S 에 대해 S 에서 I 이 실패했음을 증명합니다 (https : // github. com / rust-lang / rfcs / pull / 1560 # issuecomment-209119266). 이 증명은 관련 불확정 가져 오기를 검색하기 위해 종종 glob 가져 오기 그래프의 DFS (정점이 모듈이고 가장자리가 glob 가져 오기 임)가 필요합니다.

그러나 이러한 추가 네임 스페이스 별 작업은 실제로 차이를 만들지 않을 수 있으며 필요한 경우 피할 수 있습니다 (https://github.com/rust-lang/rfcs/pull/1560#issuecomment-209119266 참조). 매크로 네임 스페이스에만 적용되는 사소한 제한입니다.

저는 # 37198의 네임 스페이스를 병합하여 대부분의 옵션을 열어두고 실제로 제한 할 것이라고 생각하지 않았기 때문입니다. 사람들이 오늘 그것을 원하고 @ rust-lang / lang이 여러 매크로 네임 스페이스를 영원히 가지고 있어도 괜찮다면 이의가 없습니다.

뿡 빵뀨

나는 당신의 전략이 놀랍게도 효과가있을 것이라고 생각합니다. 내 개인적인 느낌은 이상 함이 무게를 당기지 않는다는 것입니다 (예 : 오늘 우리가 가지고있는 것은 괜찮습니다).하지만 어떤 방식 으로든 구현할 수 있어야합니다.

@alexcrichton 내가 전에 썼다고 생각하는 것처럼, 더 많은 힘이 필요할 때까지 기다릴 수있어 기쁩니다. 그런 다음 내가 설명한 특성이나 더 나은 것을 할 수 있습니다. 지금은 fn 적용된 속성을 확장하는 것으로 충분하다고 생각합니다.

호기심이 생겼고이 아이디어의 기본 구현을 시작했습니다 (항목에 사용 된 것으로 표시 할 속성 이름을 나타내는 proc_macro 함수의 속성 사용).

우리가 아직 안정화 할 준비가 된 지점에 도달하지 않은 것이 분명해 보이기 때문에 FCP 태그를 지 웠습니다. 저는 대화의 상태를 요약하고 특히 확고한 결정 및 / 또는 코드 기여가 여전히 필요한 오류를 강조하기 위해 노력할 것입니다.

질문 1 : 사용자 지정 파생 매크로가 걸어 다니는 항목을 변경할 수 있어야합니까?

• 아무도 그들이 _ 실제로 _ 당연히 그렇게해야한다고 생각하지 않습니다.
• YAGNI의 정신으로 처음에는 거부되었던 또 다른 모드입니다.
• 필드 이름 세트 등을 변경하는 파생은 제대로 구성되지 않아 애플리케이션 순서를 표시합니다.
  그 위험은 두 가지 방법으로 완화됩니다.
  
  
  
  • 필드 이름 / 유형 변경은 실제로 투명하게 수행 할 수 없습니다.
  
  
  • 안전에 중요한 매크로는 완전히 명시적인 구조체 패턴 을 사용하여 아무도 필드 집합을 변경하지 않았는지 확인할 수 있습니다.
  
  
• 반면에 custom derive는 새로운 impls 만 반환하면됩니다.
  
  
  
  • 스팬 정보가 더 좋습니다
  
  
  • 사용자 정의 파생은 작성하기가 더 간단합니다.
  
  
• _ 그러나 _ 많은 사용자 정의 파생은 확장을 안내하기 위해 사용자 정의 속성을 사용하며 경고 / 오류를 생성합니다.
  
  
  
  • 현재 기술은 AST에서 제거하는 것입니다.
  
  
• _ 또한 : _ 우리는이 물건을 최대한 빨리 세상에 내보내고 싶습니다. 긴 실험이나 급격한 변화를 원하지 않습니다.

제안 :

• 모든 것을 그대로 유지하고 나중에 지원 중단
  
  
  
  • 편리하고 다소 불행 함
  
  
• 속성의 화이트리스트로 #[proc_macro] 를 확장하고 rustc에게 그것들을 "중고"로 간주하고 무시하라고 지시하십시오.
  
  
  
  • 단순함, 주요 사용 사례 포함
  
  
  • 그러나 누군가 그것을 구현해야합니다 ( 아마 @keeperofdakeys! )
  
  

질문 2 : 사용자 지정 파생이 다른 매크로와 동일한 네임 스페이스를 공유해야합니까?

다음에 대한 인수 :

• 일반적으로 더 적은 네임 스페이스가 더 좋으며 해결 실행 시간을 줄입니다.
• 이전 버전과의 호환성 , 나중에 네임 스페이스를 제거 할 수 없음
• 대문자 표기 규칙 ( #[derive(Foo)] 대 foo! )이 이미 목적을 달성했습니다.
• use foo::Bar 은 어쨌든 당신이 의미하는 네임 스페이스를 구분할 수 없으므로 공유하지 않을 경우 혼동 할 여지가 적습니다.

반대 주장 :

• #[cfg()] 대 cfg!() #[cfg()] 대 cfg!() 가 오늘 발생합니다 (그러나 이들 중 어느 것도 사용자 정의 파생이 아니며 매크로가 실행중인 컨텍스트를 알려 줌으로써 수용 할 수 있음)
• _user_ 관점에서, 어떤 사람이 언급하고 있는지 혼동하지 않을 것입니다.

제안 :

• "사용자 지정 파생"네임 스페이스로 분할
• 현상 유지

다른 것들?

다른 미해결 질문이 있습니까?

돌연변이 문제에 대한 잠재적 해결책 :

유형이 TokenStream -> TokenStream 인 사용자 정의 파생 대신 유형이 있습니다.
Item -> TokenStream , 여기서 Item 는 두 가지 방법으로 시작하는 불투명 한 유형입니다.

• item.tokens() , 오늘 전달 될 TokenStream 반환
• item.use_attrs(name) , 지정된 이름의 모든 속성이 사용됨으로 표시됩니다.

반환 된 TokenStream 에는 파생 된 impl 만 포함됩니다.
결국 편의 기능 (예 : 항목의 필드 / 변형에 대한 반복) 또는 syntax_ext::deriving::generic 있는 것과 같은 상위 수준 파생 API를 사용하여 Item 의 API에 추가 할 수 있습니다.

#[proc_macro_derive] (예 : https://github.com/rust-lang/rust/issues/35900#issuecomment-258315395의 질문 1에 대한 두 번째 제안) 하게되어 기쁩니다. 내 Item -> TokenStream 제안.

기본 항목을 변경할 수있는 사용자 정의 파생을 안정화하는 것은 실수라고 생각합니다. 우리가 돌연변이를 허용하여 희생하는 스팬 정보는 이미 문제를 일으키고 있습니다. 예를 들어, # 37563 수정과 # 36218 수정 중에서 선택해야합니다.

명령형 화이트 리스팅의 매력이 보이지 않습니다. 누구나 사용 사례를 생각해 낼 수 있습니까?

이 코드가 컴파일되는 것이 의도적 / 원하는 것인지 잘 모르겠습니다.

#![feature(proc_macro)]

#[proc_macro_derive(Whatever)]
struct Foo {}

@eddyb 명령 적 화이트리스트의 고유 한 매력이 있는지 확실하지 않습니다.
Item -> TokenStream 는 더 많은 종류의 선언적 속성을 추가하는 것보다 Item 의 API를 확장하는 것이 더 쉽다는 것입니다. 그 존재는 필요로 다른 많은 사용 사례가되지 않을 수도 있습니다, 좀 더 이것에 대해 생각했다 Item 이상 TokenStream , 그래서 TokenStream -> TokenStream 선언적 화이트리스트가있는

매크로 2.0이이 API를 대체합니까? 그렇다면 확장 성은 실질적인 문제가 아니며 Item -> TokenStream api는 그다지 매력적이지 않습니다.

RFC에 따르면 @keeperofdakeys :

전반적으로 이것은 공식 "매크로 2.0"을 향한 점진적인 단계로 간주되어야합니다.

매크로 1.1의 의도는 방대한 기능을 안정화하지 않고도 정신과 구현면에서 매크로 2.0에 최대한 가깝게 만드는 것입니다. 그런 의미에서 안정적인 매크로 1.1이 주어지면 매크로 2.0에 도달하기 위해 이전 버전과 호환되는 기능을 계층화 할 수 있습니다.

https://github.com/rust-lang/rfcs/pull/1681#issuecomment -233449053 및 https://github.com/rust-lang/rfcs/pull/1681#issuecomment -233708395 및 https : // github. com / rust-lang / rfcs / pull / 1681 # issuecomment -239558657은 매크로 2.0이 도착하면 "제한된"지원 중단 만 예상됨을 나타내는 것 같습니다. 특히 : "문자열 화 토큰 트리의 패턴은 실제로 사용되지 않는 경우에도 선호되지 않습니다."

@eddyb

명령형 화이트 리스팅의 매력이 보이지 않습니다. 누구나 사용 사례를 생각해 낼 수 있습니까?

글쎄, 나는 속성의 이름이 어떤 방식 으로든 동적으로 생성되는 경우를 상상할 수 있습니다 (아마도 유형 또는 필드의 이름을 기반으로?). 따라서 미리 선언 할 수 없습니다. 그러나 일종의 인공적인 것처럼 보이며 특히 좋은 습관은 아닙니다.

@jseyfried 의 대안이 매력적이라고 ​​생각합니다. 속성을 사용 된 것으로 표시하는 필수 특성 때문이 아니라 시간이 지남에 따라 Item API가 더 풍부해질 수 있기 때문입니다. 즉, 우리는 매우 구조화 된 방식으로 필드 세트를 걷는 것을 지원하고, 우리가 처분 할 수있는 더 많은 데이터 (이름 확인과 같은)에 대한 액세스를 제공 할 수 있습니다.

물론,이 중 일부는 표준 AST API의 일부 형식 (_eventually_)에서도 제공됩니다.

타이밍에 대한 참고 사항 : 정말 다음주기에서 매크로 1.1이 안정화되는 것을보고 싶습니다. 우리가 차단 된 것은 궁극적으로 상당히 사소한 느낌입니다.

그런 정신으로 내가 설명한 문제에 대한 나의 견해 :

1. 선언적 #[proc_macro] 확장 _or_ 유형을 Item 변경하는 것에 만족합니다. 나는 또한 우리가 어떤 것을 선택하든 그것이 좋은 생각처럼 보이면 미래에 다른 것을 잠재적으로 채택 할 수 있다고 생각합니다. 먼저 구현되는 방식을 사용하고 싶습니다. =)
2. 여러 네임 스페이스에 관해서는 당분간 동일한 네임 스페이스에 보관해야한다고 생각합니다. 저에게는 대문자 사용이 이미 "사용자 지정 파생"매크로를 실제로 다른 것들과 구별한다는 사실과 하위 호환성 (즉, 옵션을 열어 두는 것)의 조합이 매력적입니다. #[cfg] 와 cfg! 구별하는 것은 우리가 다른 방식으로 처리 할 수있는 것처럼 느껴지거나 원하는 경우 분할 네임 스페이스 _then_을 도입 할 수 있습니다. 통합 네임 스페이스를 갖는 것이 특히 사용자 지정 파생 사용 사례에 해를 끼치는 것 같지는 않습니다. 이는 어쨌든 안정화에 대해 이야기하는 유일한 것입니다. 권리?

@nikomatsakis 귀하의 요약은 정확합니다. 작성해 주셔서 감사합니다! Rust 1.14에서 매크로 1.1을 얻지 못해 안타깝지만 이것이 논쟁의 여지가있는 문제라는 것을 이해합니다.

내 개인적인 느낌은 사용자 지정 파생이 속성을 제거해야하고 네임 스페이스가 하나 뿐인 모든 것을있는 그대로 안정화하는 것입니다.

저는 Item -> TokenStream API를 따르지 않습니다. 반환 된 토큰 스트림이 여전히 원래 항목을 포함합니까 아니면 추가 된 impls 만 포함합니까? &mut Item 필요하다는 뜻입니까?

@ est31 귀하의 의견 은 버그처럼 들립니다. 별도의 문제를 열 ​​수 있습니까?

나는 @nikomatsakis 의 의견에 거의 전적으로 동의합니다. 파생물이 연결된 항목을 변경할 자유 통치권이 없다는 것이 중요하다고 생각하지만 제안 된 모든 구현은 나에게 괜찮아 보입니다.

통합 네임 스페이스를 갖는 것이 특히 사용자 지정 파생 사용 사례에 해를 끼치는 것 같지는 않습니다. 이는 어쨌든 안정화에 대해 이야기하는 유일한 것입니다. 권리?

현재 Queryable! 라는 매크로를 가지고있는 디젤이 고장 났기 때문에 문제가 발생했습니다.이 매크로는 구조체를 래핑하여 Queryable 를 파생시킬 수 있습니다.

지금 당장 디젤을 사용하거나 유지하지 않는 사람으로서 (즉, 내가 제안하려는 것에 영향을받지 않는 사람으로서 : sweat_smile :), 가장 좋은 방법은 지금은 1 개의 네임 스페이스를 유지하고 디젤은 이름을 변경하는 것입니다. 해당 매크로를 derive_Queryable! 또는 이와 유사한 것으로 지정합니다. 어쨌든 이것이 안정되면 더 이상 사용되지 않을 것입니다.

제안 된 기능에 대해 PR https://github.com/rust-lang/rust/pull/37614 를 만들었습니다. 별도의 속성 #[proc_macro_attributes(..)] 를 사용하며 더 이상 반환 된 TokenStream 있는 항목을 반환 할 필요가 없습니다.

proc 매크로가 $crate 어떻게 처리해야하는지 알아보기 위해 # 37637을 제출했습니다.

명확히하기 위해,이 사용 사례가 괜찮은 것으로 간주됩니까 아니면 시스템의 오용으로 간주됩니까?

여기 에서 기존 구조체와 속성을 기반으로 새 구조체를 생성하고 하나의 구조체로 통합 할 수있는 디자인이 마음에 듭니다.

그러나 시스템이 나중에 이러한 종류의 구현을 허용하지 않도록 변경 될 수 있다면 더 많은 노력을 기울이는 대신 지금 중단 할 수 있습니다 (현재 구현은 개념의 빠른 증명 일뿐입니다).

헉헉

이전 버전과 호환되지 않는 주요 변경 사항은 더 이상 항목을 수정할 수 없다는 것입니다 (TokenStream에서 다시 전달하지 않음). 나는 impl 이외의 다른 것을 파생하는 것은 의도 된 것이 아니라고 말하고 싶지만, 당신이 이것을하는 것을 막을 수는 없습니다. 이름 충돌에주의해야합니다.

다른 주요 변경 사항은 항목에 대한 사용자 지정 속성 오류를 트리거하지 않아야하는 속성 이름 목록을 제공 할 수 있다는 것입니다.

RE : Diesel의 네임 스페이스 충돌입니다. 이 기능이 안정되면 매크로를 더 이상 사용하지 않을지, 아니면 컴파일러 확장이 필요 없는지에 대한 욕구가 있는지에 따라 달라집니다. 의심 스럽다. 내부 테스트에 여전히 유용하지만 이름을 바꾸는 것은 괜찮습니다.

입력 스트림을 수정하는 기능을 잃는 것은 불행한 일이라고 생각합니다. 주석이 달린 항목을 제거 할 수 있으므로이 시스템에서도 뱅 매크로를 사용할 수 있습니다. 나는 그 우려를 이해하지만 그들에 대한 능력을 잃는 것은 부끄러운 일입니다.

@TheNeikos @sgrif 내 관점은 입력을 심각하게 수정하는 것은

항목을 수정할 수 없다는 것은 항목의 범위 정보가 유지됨을 의미하므로 항목에 대한 오류 메시지가 훨씬 더 명확 해집니다 (또한 파생 된 출력의 오류 메시지가 더 이상 항목의 범위를 가리 키지 않고 파생 속성의 범위를 가리킴을 의미 함). 우리가 정말로 적절한 절차 적 매크로를 원한다면 사람들이이 기능을 남용하도록 허용하는 좋은 이유를 알 수 없습니다.

@TheNeikos 나는 당신이 파생하는 구조체를 모티브로하지 않는 한 파생을 통해 새로운 구조체를 생성하는 것을 허용하지 않을 것이라고 생각합니다.

제가 생각하기에 관용적이라고 생각합니다. 나는 새로운 유형을 생성하는 것이 괜찮다고 생각하지만 이러한 유형이 파생되는 특성과 관련된 유형이면 훨씬 좋습니다. 예를 들어, Iterator 구조체를 생성하는 것과 관련된 유형에 대해 IntoIterator 를 파생시킬 수 있다고 상상해보십시오. 개념적으로이 유형에 대한 동작을 유도해야하지만 해당 동작은 "특성 간체"가 아닐 수 있습니다.

헉

입력 스트림을 수정하는 기능을 잃는 것은 불행한 일이라고 생각합니다. 주석이 달린 항목을 제거 할 수 있으므로이 시스템에서도 뱅 매크로를 사용할 수 있습니다. 나는 그 우려를 이해하지만 그들에 대한 능력을 잃는 것은 부끄러운 일입니다.

흠, 나는 분명히 동정적이지만 ( @nrc가 지적했듯이) 이것은 시스템이 설계된 것이 아니며 다양한 거친 가장자리를 노출시키는 경향이 있습니다. 이것은 아마도 당신의 사용 사례에서 중요하지 않을 것입니다. 중요한 질문은 "뱅 매크로 1.1"과 같은 일로 신속하게 이동할 수있는 방법입니다.

PR이 병합되었으므로 다음날 밤에 다음 변경 사항을 확인할 수 있습니다. proc_macro_derive 함수는 더 이상 항목을 반환하지 않아야하며 (그렇게하면 유형이 두 번 정의된다는 오류가 발생 함) 이제 #[proc_macro_derive(Derive, attributes(Foo, Bar)] 와 같이 화이트리스트에 속성 이름 목록을 제공 할 수 있습니다.

cc @dtolnay , @sgrif ^

불행히도 곧 파손될 것입니다.

네, 우리 쪽에서 추적하기 위해 https://github.com/serde-rs/serde/issues/614 에 제출했습니다.

https://github.com/diesel-rs/diesel/pull/493 에서 Diesel의 파손을 수정했다고 생각합니다. 나이틀리가 다시 구축되면 확실히 알 것입니다.

따라서이 스레드를 올바르게 읽고 있다면 proc 매크로는 초기 항목에 추가 된 추가 항목 만 내보낼 수 있기 때문에 초기 항목에 더 많은 주석을 추가 할 수 없습니까? ( "형제 주석"을 허용한다는 언급이 있지만 다른 것은 없습니다.)

주석을 달고있는 구조체에 따라 다른 #[derive()] 세트로 확장되는 (작고 게시되지 않은) 크레이트에 #[derive(newtype)] proc 매크로가 있습니다. 예를 들어 #[derive(newtype)] struct Foo(u64) 는 #[derive(Clone, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)] struct Foo(u64); #[derive(newtype)] struct Foo(u64) 확장되는 반면 #[derive(newtype)] struct Foo(::semver::VersionReq) 는 #[derive(Clone, Debug, PartialEq)] struct Foo(::semver::VersionReq); 확장됩니다. 따라서 구조체 멤버는이 매크로에 의해 수정되지 않지만 다른 파생 항목이 추가됩니다 (구조물도 수정하지 않음).

이러한 구조체는 수십 개가 있으며 각각이 매크로가 확장 된 후 10 개 정도의 새로운 파생이 있습니다. 나는 모든 u64 newtypes가 하나 이상의 특성을 구현하기를 원한다는 것을 깨달으면 모든 단일 구조체 대신 newtype 매크로 코드의 한 곳에서 파생 세트를 변경할 수 있습니다.

나는 이것을 위해 macro_rules newtype! 매크로를 사용했지만 다음과 같은 이유로 proc 매크로로 전환했습니다.

• 문서 주석의 유무, pub 등의 유무는 조합 된 매크로 매치 암 없이도 무료로 처리됩니다.
• 내가 조합 매크로 매치 암을 작성하더라도 서로 충돌하지 않는 순서를 찾는 것은 어려웠습니다.

안타깝게도 더 이상이 작업을 할 수 없습니다.

이 기능의 향후 호환성이 안정적이라는 점 : 플러그인 함수가 "순수"일 필요가 없기 때문에 함수에 부여 된 객체의 순서가 향후에 변경되거나 rustc가 멀티 스레드를 구현하면 브레이킹 체인지가 될 것입니다. 컴파일?

@ est31 시간이 있다면 앞서 언급 한 IPC 격리를 제거해야합니다.

가장 최근의 변경 이후 디젤에서 ICE를 지속적으로보고 있습니다.

../src/librustc_metadata/decoder.rs:490 : entry : id not found : DefIndex (1) in crate "diesel_codegen"with number 28

@sgrif 는 # 37793에 의해 수정 될 # 37788 문제가 될 것입니다 (내일 밤에 끝날 수 있기를 바랍니다 ...).

@ est31 야간 빌드가 시작되기 전에 병합하기에는이 시간이 너무 늦습니다.

https://github.com/rust-lang/rust/issues/37839 는 자체적으로 proc_macro 크레이트를 사용하는 lib 크레이트를 사용할 때 발생하는 문제입니다. AFAICT 테스트는 proc 매크로 모듈 만 컴파일하거나 proc 매크로 모듈과 proc 매크로를 직접 참조하는 bin 모듈을 컴파일하기 때문에 이에 영향을받지 않습니다.

편집 : 이제 수정되었습니다!

@Arnavion # --target 사용할 때 문제가 계속 발생합니다. 여전히 중단되는 --target 를

@rfcbot fcp 병합

이제 화이트리스트 속성 기능 이 구현되었으므로이를 안정화해야한다고 생각합니다! Serde, Diesel 및 기타 사용자-현재 디자인이 작동하지 않는 경우 이제 개체에 대한 변경 사항입니다. =)

cc @sgrif @erickt

@nikomatsakis 팀원 이이를 병합 할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀의 검토입니다.

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

현재 나열된 문제가 없습니다.

이러한 검토자가 합의에 도달하면 최종 의견 기간이 시작됩니다. 이 과정에서 아직 제기되지 않은 주요 문제를 발견하면 알려주세요!

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

가까운 장래에 뱅 매크로가 탐색되는 것을보고 싶습니다. 하지만 이의는 없습니다.

@rfcbot 검토

현재 TokenStream이 구문 분석에 실패 하면 빈 LexError가 반환 됩니다. 구문 분석에 실패한 토큰과 같은 더 나은 오류 메시지를 여기에 반환 할 수 있습니까? 라이브러리 사용자는 이러한 종류의 오류 메시지를보고 싶지 않을 것입니다.

예, 매크로 작성자에게 편리합니다. 오류를 찾기 위해 스트림을 파일에 기록하고 놀이터에서 확인해야했습니다.

매크로에 대해 더 나은 버그 보고서를 제출하는 경우 사용자에게도 도움이 될 것이라고 생각합니다.

https://github.com/rust-lang/rust/pull/38140 에서 사용자 지정 파생 선언이 공개되도록 강제하고 있습니다. 이론은 우리가 언젠가 사적인 파생물을 원할 수 있고 정의 함수의 가시성을 기반으로 구별을하고 싶을 것입니다. 어쨌든 이것은 보수적 인 선택입니다. 이 기능을 안정화하고 있기 때문에 병합하기 전에 사람들이 볼 수 있도록 하루나 이틀 동안 담그는 것으로 생각했습니다.

# 37480이 닫히면 체크리스트에 반영되어야합니다.

결정된

@pnkfelix 나는 당신이 PTO에 있고 나는 완전히 선상에 있다고 믿기 때문에 당신을 위해 당신의 상자를 체크 할 자유를 얻었습니다. 그렇지 않은 경우 알려주십시오!

: bell : 지금은 위 의 에 따라 최종 댓글 기간을 입력합니다 . :벨:

psst @nikomatsakis , final-comment-period 레이블을 추가 할 수 없습니다. 그렇게 해주세요.

임박한 안정화는 맨 위에있는 체크리스트의 나머지 알려진 버그가 먼저 수정 될 것이라고 가정합니까? 아니면 안정화를 막고 있지 않습니까?

지금 두 가지가 있습니다.

• # 36935는 해결되었다는 댓글이 있습니다.
• # 36691은 저에게 방해가되지 않는 것 같습니다. 제가 믿는 어떤 것도 깨뜨리지 않고 원한다면 언젠가 이것들이 mod foo; 로 확장되도록 할 수 있습니다.

야! 이것은 RFC 1636 문서 감사입니다. 이것은 RFC 1636이 채택 된 이후 안정화해야 할 첫 번째 주요 기능이며이 경우이를 잘 따라야합니다.

RFC는 다음과 같이 설명합니다.

기능을 안정화하기 전에 기능은 이제 다음과 같이 문서화됩니다.

• 언어 기능 :
  
  
  
  • Rust Reference에 문서화되어야합니다.
  
  
  • The Rust Programming Language에 문서화되어야합니다.
  
  
  • 예제에 의해 Rust에 문서화 될 수 있습니다.
  
  
• 언어 기능과 표준 라이브러리 변경 사항은 모두 다음을 포함해야합니다.
  
  
  
  • 변경 로그를위한 한 줄
  
  
  • 긴 형식의 릴리스 발표에 대한 긴 요약입니다.
  
  

이를위한 올바른 프로세스는 무엇입니까? 이 문제의 최상위 댓글에 체크리스트 항목을 추가해야합니까? 아니면 문서 추적을 위해 새 문제를 만들어야합니까? 1.15 릴리스까지 트리에서 이러한 요구 사항을 충족하는 문서가 있어야하는 것 같습니다.

cc @ rust-lang / docs

@withoutboats 감사

나의 상상은 항상 안정화 결정과 실제 안정화가 분리되어 있다는 것이었다. 즉, @ rust-lang / lang은 "이것은 안정적으로 만들 수 있습니다"라고 말할 수 있지만 게이트를 제거하겠다는 약속은 문서가 존재 함을 보장합니다. 불안정한 책이 존재 하는 세상에서 이것은 문서를 거기에서 안정된 문서로 끌어 올릴 것입니다. 하지만 그때까지는 상황이 약간 어색합니다.

우리가 방금 릴리스를 받았으므로 내 계획은 다음과 같이하는 것이 었습니다.

1. 이것이 FCP를 떠날 때까지 기다리십시오.
2. 문서를 작성하십시오. (이 경우에는 쓸 계획이었습니다)
3. 안정화 PR을합니다.

2 개와 3 개를 결합한 것 같습니다.

/ cc @ rust-lang / core, 이것은 팀 간 문제이기 때문입니다.

@steveklabnik 은 나에게 좋을 것 끝나기 전에도) 언제든지 문서를 방문하는 것이 좋습니다. 여기서 FCP는 우리가 실수로 들어가는 데 오랜 시간이 걸렸기 때문에 어쨌든 일종의 유사 마무리입니다.

또한 1.15 베타 브랜치로의 안전한 백 포트를 보장 할 수 있도록 이러한 정보를 빠르게 가져 오는 것도 좋습니다!

내가 이것을 처음으로 친다면 그렇게 나쁠 수는 없지만 알려진 버그 아래에 포함합시다 : 사용자 정의 파생이있는 구조체 내부의 유형 매크로를 사용하면 ICE https://github.com/rust-lang/ 녹 / 문제 / 38706

https://github.com/rust-lang/rust/pull/38737 은 유형 매크로 ICE : heart :를 수정합니다

방금 proc_macro 상자에 대한 문서와 관련하여 # 38749를 만들었습니다.

Macros 1.1이 1.15에서 안정화 될 것이라는 내용을 여러 번 읽었지만 2 주 전에 출시 된 1.15.0-beta.1과 최소 extern crate proc_macro; 은 여전히 ​​야간 4ecc85beb 2016에서 기능 게이트가 있습니다. -12-28. 안정화 변경을 백 포트 할 계획입니까?

@SimonSapin 네, 그게 계획 이었지만 우리는 그것을 실현해야합니다!

그것은 여전히 ​​계획입니다 : p

사용자가 #[derive(Foo)] #[foo_def = "definition.json"] struct MyStruct; 하면 매크로 핸들러는 "현재 디렉토리"가 무엇인지 알 수 없으므로 definition.json 찾을 수 없습니다.

이것은 설계에 의한 것이기 때문에 고치기가 쉽지 않을 것입니다. 어쨌든 이것을 고치기에는 너무 늦었다 고 생각합니다.

Span -> FileMap -> 파일 이름-> 디렉토리로 이동할 수 있습니다. 빠진 것은 proc_macro 통해 정보에 액세스하는 것입니다.

또한 컴파일러에게 definition.json 종속성을 추가하도록 지시하여 빌드가 수정 될 경우 더티가되도록해야합니다.

proc 매크로는 env::var("CARGO_MANIFEST_DIR") 를 사용하여 매크로 호출을 포함하는 상자의 Cargo.toml이 포함 된 디렉토리를 가져올 수 있습니다. 아마도 foo_def 는 그것에 상대적입니다. https://github.com/dtolnay/syn/issues/70#issuecomment -268895281을 참조

@tomaka 예, FileMap을 돌연변이에 의해 수행 될 수있는 이 어떻게 '입니다 include_str! 매크로를 수행합니다.

아마도 foo_def는 그것에 상대적입니다.

Cargo.toml에 상대적인 경로를 입력해야하는 것은 그리 직관적이지 않다고 생각합니다.

이는 FileMap을 변경하여 수행 할 수 있습니다. 예를 들어 include_str! 매크로가 수행합니다.

예, 할 수 있다는 것을 압니다. 현재의 절차 적 매크로 API로는 할 수 없습니다.

매개 변수는 Item 입니다. 해당 항목에서 범위를 검색하는 메서드를 추가하는 것은 허용되지만 Item 에 메서드를 추가하여 컴파일러에게 종속성을 추가하도록 요청하는 것은 해킹 IMO입니다.

Span-> FileMap-> 파일 이름-> 디렉토리로 이동할 수 있습니다.

이러한 API (특히 FileMap )가 안정화 될 경로에 있습니까?

그럴 필요는 없습니다. 사실 저는 내부를 안정화하고 싶지 않습니다. 대신 Span 에 대한 정보 (예 : 줄, 열, 파일 이름)를 추출하는 API를 안정화 할 수 있습니다.

내 상자에서이 오류가 발생했습니다. 무슨 일이야?

`` error: Cannot use #! [feature (proc_macro)] and #! [feature (custom_attribute)] 동시에
````

@alexreg #[derive] 하고 있다면 이제 안정적입니다. #![feature(proc_macro)] 필요하지 않습니다.

뿡뿡
proc_macro_derive s (매크로 1.1)가 이제 안정적입니다. #![feature(proc_macro)] 제거하면됩니다.

#[proc_macro_attribute] 최근 #![feature(proc_macro)] 기능 게이트 뒤에 착륙했습니다. #![feature(custom_attribute)] 와 호환되지 않습니다. #![feature(custom_attribute)] 교체가 완료되면 더 이상 사용되지 않습니다 (https://github.com/rust-lang/rfcs/pull/1755).

@jseyfried proc_macro 에 대한 추적 문제가 닫혀 있고 관련 정보가 포함되어 있지 않으므로 변경해야한다고 생각합니다.

감사합니다. 말이 되네요.

@abonander 예, #![feature(proc_macro)] 은 이제 # 38356을 확실히 가리켜 야합니다. # 38842를 검토 할 때 확인 했어야합니다. PR을 제출할 수 있습니까?