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 edit: переместил контрольный список в OP)

cc @nrc @petrochenkov @durka @Ralith

@jseyfried Я столкнулся с проблемой, из-за которой, если устаревший макрос и атрибут с тем же именем импортируются в одну и ту же область видимости, попытка использовать атрибут вызывает ошибку, заключающуюся в том, что макросы нельзя использовать в качестве атрибутов. Можем ли мы сделать эту работу так, чтобы и то и другое могло быть в одной и той же области и использоваться по назначению?

@abonander Все макросы (bang, attribute и derive) используют одно и то же пространство имен, поэтому мы не можем использовать два разных макроса с одинаковым именем в одной и той же области. Однако мы могли бы улучшить это сообщение об ошибке - не могли бы вы открыть проблему?

Извини, что опоздал на вечеринку. Я доволен направлением раскрытия токенов, а не AST, но у меня есть некоторые опасения по поводу конкретного TokenStream API, предложенного в RFC :

pub enum TokenKind {
    Sequence(Delimiter, TokenStream),

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

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

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

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

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

pub enum StringKind {
    Regular,
    Byte,
}

Неясно, был ли этот API задуман как полный план, который был принят при объединении RFC, или как пример, который будет разработан позже.

Как правило, это далеко от «нормального» синтаксиса Rust, принятого компилятором вне макросов. В то время как некоторые макросы захотят проанализировать какой-то специальный предметно-ориентированный язык, другие захотят проанализировать «настоящий» синтаксис Rust и разобраться в нем.

1. (Незначительное) Я не думаю, что Eof необходимы. Iterator , вероятно, будет использоваться для перебора TokenStream а Iterator::next уже возвращает None чтобы сигнализировать об окончании итерации.

2. (Незначительное) Я не думаю, что нужны Exclamation , Dollar или Semicolon . Например, сопоставление по Punctuation('!') не сложнее.

3. (Незначительный) Как уже упоминалось в RFC PR, мы могли бы опустить комментарии, которые не являются комментариями документа. (Любой вариант использования, который хочет сохранить комментарий, вероятно, также хочет сохранить пробелы.)

4. Насколько я могу судить, что делать с многосимвольными операторами (каждый из которых, вероятно, должен содержать один токен) все еще остается открытым вопросом. Возможное решение обсуждается в PR-комментариях, но похоже, что оно не вошло в текст RFC.

5. Числовые литералы отсутствуют. Предполагается, что макросы сами разбирают [Punct('1'), Punct('_'), Punct('2'), Punct('3'), Punct('4'), Punct('.'), Punct('5'), Punct('e'), Punct('6')] для вычисления литерала? Они даже не могут использовать str::parse::<f32> для этого, поскольку синтаксис, который он принимает, не совпадает с синтаксисом литерала Rust (например, в середине может быть _ ).

   Я полагаю, что здесь есть проблема стабильности. Можем ли мы ввести новые числовые типы, такие как 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. // Слово определено в Приложении 31 к стандарту Unicode -

   Это определение должно быть более точным. UAX 31 определяет несколько различных вариантов синтаксиса идентификатора, и ни один из них не называется «словом». Но именно выбор того, какой именно вариант мы хотим, является причиной того, почему идентификаторы, отличные от ASCII, в настоящее время

   Вместо этого я думаю, что это должно быть определено как «все, что текущий компилятор принимает в качестве идентификатора или ключевого слова» (которое может измениться согласно # 28979). Возможно, с публичным API pub fn is_identifier(&str) -> bool в libmacro.

7. Строки Unicode и байтовые строковые литералы используют один вариант токена, что я считаю неправильным, поскольку представления их значений в памяти имеют разные типы ( str vs [u8] ). Также неясно, предназначен ли компонент text: Symbol для того, чтобы быть буквальным фрагментом исходного кода или значением после разрешения экранирования обратной косой черты. Я думаю, что однозначно должно быть второе. (Для сравнения, Char(char) должно быть последним, поскольку \u{A0} требует более одного char для буквального представления.)

другой способ написать макросы высокого уровня - использовать макросы типа lisp, но для этого потребуется представление s-выражения для всей rust ast.

@SimonSapin ,

Как уже упоминалось в RFC PR, мы можем опустить комментарии, которые не являются комментариями документа. (Любой вариант использования, который хочет сохранить комментарий, вероятно, также хочет сохранить пробелы.)

Пожалуйста, не надо. У меня есть вариант использования, в котором я хочу использовать (но не сохранять - вместо этого они будут записаны в отдельный продукт компиляции) комментарии в синтаксисе.

В частности, я хочу создать макросы перевода, которые будут загружать переводы строки из отдельного исходного файла (ов), и я хотел бы сгенерировать список строк, которые будут переводиться как побочные продукты в отладочной сборке. И должен быть способ включить комментарии, которые будут отправлены в этот список (rust-locale / rust-locale # 19). Поэтому имеет смысл использовать синтаксис комментариев, и макрос должен их видеть.

Я согласен с другими пунктами в этом посте.

@ jan-hudec
Даже если бы у нас не было TokenKind::Comment , вы все равно могли бы использовать комментарии, просматривая содержимое промежутков между последовательными токенами.

Я не думаю, что у нас не должно быть TokenKind::Comment чтобы поощрять процедурные макросы игнорировать комментарии, чтобы пользователи могли свободно добавлять комментарии к вызовам макросов, не беспокоясь об изменении семантики.

@ jan-hudec Есть ли причина, по которой атрибуты не работают с вашим решением?

@abonander , атрибуты абсолютно не имеют смысла. Переводимые строки действуют как литералы, а не как элементы. Но извлечение их во время компиляции было бы просто для удобства - это всегда можно выполнить как отдельный синтаксический анализ (и на самом деле может так и получиться, потому что мне нужно видеть _все_ из них в ящике, и инкрементная компиляция сломает это).

Я хочу создать процедурный макрос, основанный на производном serde (и поэтому напрямую вызывая функции потока токенов serde), но я не могу сказать, что хочу использовать serde derive как библиотеку, а не как процедурный макрос. Это не только для получения макросов, я вижу, что подобное требуется и для «обычных» процедурных макросов.

Сейчас мое единственное решение - разветвление serde_derive.

Проблема в этом сообщении об ошибке от rustc:

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

Это легко удалить и заставить его работать, но есть также некоторая сложность, которую я не знаю, как решить - ящик процедурных макросов вполне может захотеть как использовать proc-макрос, полученный из другого контейнера процедурных макросов, так и вызов функций для генерации производной для нижестоящего пользователя. Как бы это выглядело? Есть ли что-нибудь подобное в настоящее время, когда ящик можно связать двумя разными способами по запросу потребляющего ящика?

@aidanhs

Ящик процедурных макросов, вероятно, может захотеть как использовать процесс-макрос, производный от другого контейнера процедурных макросов, так и вызывать функции для генерации производного макроса для нижележащего пользователя. Как бы это выглядело?

Вы не можете получить доступ к функциям (или чему-либо еще, кроме процедурных макросов) из ящика proc-macro . Если вы хотите использовать функции TokenStream -> TokenStream и соответствующие процедурные макросы, вам необходимо поместить функции TokenStream -> TokenStream в отдельный ящик, отличный от proc-macro , а затем также иметь ящик proc-macro который просто делегирует эти функции.

Этот RFC будет в основном реализован после приземления # 40939.

Предоставьте авторам proc_macro возможность создавать расширения, которые используют элементы в заранее определенном ящике. foo не требуя от пользователя макроса включать extern crate foo; в корень ящика.

Предположим, я хочу представить один ящик, который содержит как немакро-элементы, так и процедурный макрос, который ссылается на указанные элементы. Когда приземлится # 40939, станет ли этот узор из трех ящиков идиоматическим способом достижения этой цели?

1. Поместите все элементы, не относящиеся к макросам, в foo_runtime
2. Реализуйте процедурный макрос в foo_macros , при необходимости обращаясь к символам в foo_runtime
3. Добавьте последний "фасадный" ящик foo который pub use s элементы из foo_runtime и foo_macros
   
   
   
   • Это единственный ящик, который пользователь импортирует напрямую.
   
   
   • Это работает, потому что система гигиены фиксирует макросы так, чтобы они указывали на правильный ящик.
   
   

Я спрашиваю, потому что мой вариант использования включает в себя импорт двух ящиков , и было бы здорово, если бы я мог обойтись только одним.

@lfairy Я думаю, что шаблон "два ящика" будет идиоматическим способом:

1. Поместите все элементы, не относящиеся к макросам, в foo
2. Реализуйте процедурный макрос в foo_macros , обращаясь к символам в foo мере необходимости, например

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

1. pub use элементы из foo_macros в foo .

Это работает, потому что система гигиены фиксирует макросы так, чтобы они указывали на правильный ящик.

Повторный экспорт процедурного макроса в другой ящик не влияет на разрешение имен из процедурного макроса.

@jseyfried : Вы знаете, работает ли этот трюк с реэкспортом и с пользовательскими производными? Потому что у этих ящиков есть точно такое же ограничение - невозможность экспорта каких-либо предметов.

@ colin-kiegel
Ящики настраиваемого извлечения - это просто ящики макросов процессов, в которых есть только #[proc_macro_derive] s.
С помощью #[feature(proc_macro)] вы можете реэкспортировать пользовательские производные в обычных ящиках, точно так же, как вы можете реэкспортировать другие макросы proc.

@jseyfried Я в курсе ситуации на данный момент, я задал вопрос, потому что не думаю, что он идеален, и надеялся обсудить его. В описываемой вами ситуации «делегирование» / повторное использование процедурных макросов из другого ящика становится вопросом убеждения автора макроса (в данном случае serde) разделить свои процедурные макросы на два ящика. Если я могу вызывать процедурные макросы, как обычные функции, автору апстрима даже не нужно знать, что я использую их ящик.

Тем не менее, я осознаю опасность совместимости - точное дерево токенов, сгенерированное макросом, становится частью стабильного интерфейса, поэтому, если serde изменит способ генерации Derive в версии патча, и я написал хрупкий макрос, мой макрос будет сломан для каждого нового пользователя моего ящика (в отличие от хрупкого макроса в текущем случае, когда в худшем случае он будет работать только для определенных входов, но последовательно).

@jseyfried

Вытягивает ли это foo из текущего списка грузовых отправлений? Звучит плохо (то есть будет ли он делать что-нибудь особенно глупое, если есть 2 ящика с именем foo подключенные к текущему двоичному файлу?).

@aidanhs Это будет серьезное изменение / дополнение языка, которое потребует создания собственного RFC.

@ arielb1

Вытягивает ли это foo из текущего списка грузовых отправлений? Это звучит плохо

Да, к сожалению, имена extern crate кавычках не являются гигиеничными, т.е. разрешение зависит от того, какие имена ящиков попадают в область действия, в которой используется процедурный макрос. Мы можем смягчить это, используя уловку реэкспорта (т.е. реэкспорт foo_macros в foo чтобы мы знали, что foo будет в области действия), но это не защищает от ошибок неоднозначности при наличии двух ящиков с именами foo .

Я думаю, что лучшим решением здесь является добавление зависимостей фазы 1 (то есть целевого хоста против целевого) к ящикам Cargo.toml для proc-macro помощью аргумента командной строки --target-extern . Это позволит нам явно перечислить имена extern crate в области видимости внутри quote! .

@jseyfried

Идея состоит в том, что ящик proc-макроса будет зависеть от своих «целевых» метаданных, верно?

@ arielb1 Да, именно так.

Этот RFC будет в основном реализован после приземления # 40939.

@jseyfried Готовы к стабилизации, когда

Готовы к стабилизации, когда появится этот PR?

Нет, мы хотим получить некоторый опыт работы с API перед стабилизацией и, возможно, будущей гигиеной для extern crate names (т.е. решить эту проблему , на которую указал

Мы, вероятно, захотим внести критические изменения в этот API; @eddyb предложил / рассмотрел возможность обобщения OpKind на все деревья токенов. Кроме того, мы можем изменить то, как мы обрабатываем комментарии к документам, литералы с плавающей запятой и т. Д. В целом, API в этом PR еще не достаточно зрел, чтобы рассматривать возможность стабилизации.

@bstrie, к сожалению, RFC для ускорения стабилизации макроса proc (с ограниченным api, где, например, потоки токенов доступны только через их строковое представление), например, стабилизация макроса derive не удалась: https://github.com/rust-lang/rfcs/ тянуть / 1913

@ est31 Скорее отложено - после небольшого опыта работы с этим API мы могли бы договориться о подмножестве, которое мы можем

API на основе String плохо взаимодействует с декларативными макросами 2.0 и уже сегодня ограничивает его, даже без макросов 2.0 и только с #[derive] s. Мы хотим избежать распространения API на основе String насколько это возможно, чтобы избежать проблем при переходе людей на макросы 2.0.

Я открыл проблему из- за того, что #[proc_macro_attribute] видимому, не расширяет методы черт (может быть, элементы черт в целом?)

Поскольку теперь это проблема отслеживания ящика proc_macro и его новых API, я подумал, что тоже запишу некоторые мысли. Я опубликовал ящик под названием proc-macro2 который должен быть точно таким же, как ящик в дереве proc_macro за исключением того, что он обеспечивает возможность компиляции на стабильном Rust. Затем он также имеет возможность использовать функцию для ночной компиляции Rust, чтобы получить более точную информацию о диапазоне. Эта библиотека призвана стать основой для других библиотек, таких как syn , и при разработке syn мы обнаружили несколько недостатков, которые мы, возможно, захотим исправить непосредственно в proc_macro :

• Для некоторых типов литералов не существует конструктора Literal . Это можно обойти с помощью строкового анализа с последующим синтаксическим анализом, но было бы здорово иметь возможность создавать их напрямую, без необходимости проходить через строковый API.
  
  
  
  • Необработанные строки - r###" foo "###
  
  
  • Необработанные байтовые строки - rb#" foo "#
  
  
  • Байтовые литералы - b'x'
  
  
  • Комментарии документа - в настоящее время они представлены как токен Literal .
  
  
• Невозможно проверить Literal и извлечь его значение. Прямо сейчас мы полагаемся на literalext crate для to_string литерала и повторно анализируем его, но эта информация теоретически уже хранится в Literal и было бы неплохо иметь возможность получить доступ к нему.
• Отображение токенов в некоторых случаях может быть истолковано как немного странное. А именно прямо сейчас комментарии документа сопоставляются с типом Literal .

Я считаю, что все остальные проблемы, возникающие здесь , с тех пор решены.

Я обнаружил сбой при тестировании с #![feature(proc_macro)] который влияет на пользовательские производные с #[proc_macro_derive(foo, attributes(foo))] . То есть настраиваемая производная операция, имя атрибута которой совпадает с именем настраиваемой производной формы. Один из таких ящиков - мой - цепочка извлечения ошибок, в которой есть #[derive(error_chain)] #[error_chain(...)] struct ErrorKind { ... } . Другой - derive-new, в котором #[derive(new)] #[new] struct S; . Не знаю, есть ли другие.

Для такого кода компилятор жалуется на второй атрибут "foo" is a derive mode . Это сделано намеренно или это можно исправить? Если это умышленно, мне нужно подготовиться к переименованию моего пользовательского наследника в ErrorChain или что-то в этом роде.

@Arnavion
В общем, это было намеренно - поскольку proc_macro_attribute s необходимо раскрыть перед производным, если new было proc_macro_attribute тогда расширение было бы неоднозначным. Можно было бы специально разрешить new быть proc_macro_derive , но я не уверен, что это того стоит (также может быть угроза совместимости в будущем).

В общем, это было намеренно - поскольку proc_macro_attributes необходимо раскрыть перед производным, если new было proc_macro_attribute тогда расширение было бы неоднозначным.

Хорошо, я переименую #[derive(error_chain)] в #[derive(ErrorChain)] .

Можно было бы специально разрешить new быть proc_macro_derive , но я не уверен, что это того стоит (также может быть угроза совместимости в будущем).

Конечно, я не просил, чтобы new в особом корпусе. Это был просто пример одного из двух proc_macro_derive , о которых я знаю, которые сломаны этим.

@Arnavion Извините, мой последний комментарий был не самым ясным - я имел в виду не особый случай new специально, но разрешил #[derive(some_macro)] #[some_attr] struct S; когда some_attr преобразуется в proc_macro_derive . Когда some_attr преобразуется в proc_macro_attribute , это должно быть ошибкой двусмысленности; сегодня это ошибка двусмысленности, если some_attr разрешается в любой макрос.

Да я получил его.

( Надеюсь, это подходящее место для такого вопроса. )

Какой у этого статус?

• [] Предоставить авторам proc_macro возможность создавать расширения, которые используют элементы в заранее определенном ящике foo не требуя от пользователя макроса включать extern crate foo; в корень ящика (PR # 40939 ).

PR приземлился, но флажок все еще не установлен. @jseyfried кое-что упомянул здесь, и, похоже, это работает. Однако, похоже, он вообще не работает с use :

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

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

Я что-то упускаю? Каким идиоматическим способом получить символы use из внешнего ящика, импортированного в макрос?

Вы не можете использовать use см. Https://github.com/rust-lang/rfcs/issues/959. Но для макроса использование полного пути каждый раз не является недостатком. (Думаю, кроме черт характера)

@parched Спасибо за

В моем макросе я хочу позволить пользователю написать что-то похожее на сопоставление совпадений. В частности, пользователь пишет Term и это может быть либо вариант перечисления, либо простое имя переменной, которое связывает значение соответствия. Чтобы написать псевдокод с синтаксисом macro_rules! :

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

Теперь я хочу, чтобы пользователь мог просто указать имя варианта без имени перечисления. Таким образом, я бы вставил оператор use my_crate::AnEnum::*; в сгенерированный код. Но поскольку это невозможно (прямо сейчас), мне нужно проверить для себя, является ли $matcher вариантом перечисления или нет.

Надеюсь, мое объяснение понятно. Я просто хотел дать еще один вариант использования use в сгенерированном макросом коде.

@LukasKalbertodt Не могли бы вы просто использовать my_crate::AnEnum::$matcher => {} в match ?
Неважно, я ваша проблема - я считаю, что для этого нам понадобится https://github.com/rust-lang/rfcs/issues/959 .

@jseyfried Нет: $matcher может быть либо вариантом имени (в этом случае ваше решение будет работать), либо простым именем переменной, как в match x { simple_var_name => {} } . В последнем случае это не сработает, AFAICT. (кстати, я просто хотел упомянуть еще один вариант использования, чтобы показать, что использование use важно)

@jseyfried

В общем, это было намеренно - поскольку proc_macro_attributes необходимо раскрыть перед производным, если new было proc_macro_attribute тогда расширение было бы неоднозначным.

Хорошо, я переименую #[derive(error_chain)] в #[derive(ErrorChain)] .

Кажется, что атрибуты настраиваемых производных также конфликтуют с макросами macro_rules вместо того, чтобы переопределять их, как это делают настраиваемые производные на основе порядка импорта. То есть этот код компилируется:

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

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

Это соответствует поведению текущей стабильной версии Rust, за исключением того, что (1) действительно работает в стабильной версии. Я даже явно задокументировал, что пользователям, желающим использовать #[macro_use] с ящиком error-chain , необходимо будет импортировать его перед импортом derive-error-chain .

Но даже если я переименую пользовательский производный код в ErrorChain чтобы (1) работал с функцией proc_macro (что уже является одним критическим изменением для стабильного кода):

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

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

он по-прежнему не компилируется - атрибут в (2) выдает ошибку: macro `error_chain` may not be used in attributes потому что макрос macro_rules явно конфликтует с атрибутом, зарегистрированным пользовательской производной, вместо того, чтобы быть переопределенным, как в первом случае.

Поэтому мне нужно переименовать и настраиваемую производную, и ее атрибут. Атрибут используется намного чаще (по одному для каждого варианта перечисления), чем пользовательское производное (по одному для каждого перечисления), так что это более серьезное критическое изменение, чем я ожидал. Я понимаю, что это сложная ситуация моей собственной конструкции (повторное использование имени макроса macro_rules для настраиваемого производного процесса и его атрибута), но это также код, который компилируется в стабильной версии, так как настраиваемые производные были стабилизировалась, так что у меня не было причин думать, что это будет проблемой шесть месяцев спустя.

Можно ли сделать так, чтобы атрибуты настраиваемых производных переопределяли макросы macro_rules точно так же, как настраиваемые производные сами переопределяют макросы macro_rules ? На самом деле я не понимаю, как между ними может быть какая-то двусмысленность, но я предполагаю, что это та же причина, что и при импорте макроса macro_rules после пользовательского производного с тем же именем - все макросы помещаются в одно и то же пространство имен без учета того, что это за макрос.

Есть ли менее формальное "место" для разговора о макросах proc? Нравится канал IRC #rust-proc-macro ? Я бы хотел время от времени задавать небольшие вопросы об этой функции, но мне кажется неправильным спамить эту ветку: see_no_evil: А в канале #rust большинство людей не работали с proc-макросами и особенно новый 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, так как это то, с чем я больше всего знаком.

Я лично работаю над реализацией схемы syntax-rules для схемы R7RS в моем собственном проекте, и я обнаружил, что syntax-case может служить основой для поддержки как антисанитарных, так и гигиеничных макросистем ( defmacro и syntax-rules ). GNU Guile делает это. syntax-case также поддерживает фендеры, которые могут выполнять дополнительную проверку предикатов в списках синтаксических объектов (или что-то среди строк TokenStream в схеме). Я вижу, что над Mark работают, и похоже, что он вдохновлен привязками как наборами областей видимости .

Кроме того, должны ли мы также обсудить, должны ли поддерживаться произвольные вычисления во время компиляции? Racket фактически использует полностью «фазовый» подход к вещам, похоже, с begin-for-syntax допускающим определения и вычисления (?) На уровне времени компиляции во время расширения макроса. .

Контроль над гигиеной очень возможен с помощью (datum->syntax <thing-to-copy-scope-from> <thing-to-apply-scope-to>) в Scheme, что позволяет вам выйти из области действия макроса и вместо этого взять область действия объекта за пределами непосредственной области.

Возьмите этот пример из языка программирования схем, 3-е изд. Р. Кент Дибвиг (Chez Scheme, теперь в Cisco Systems): http://www.scheme.com/tspl3/syntax.html . Пример показывает (include "filename.scm") как макрос syntax-case и позволяет интерпретатору использовать макрос для настройки среды выполнения для чтения из файла и продолжения оценки. Более глубокий вопрос здесь заключается в том, хотим ли мы, чтобы система макросов позволяла таким вещам происходить во время расширения макроса и запускала вычисления во время компиляции, такие как запуск импорта файла (хотя, похоже, это происходит в функциях прямого компилятора, так что, возможно, мы не хотим этого делать).

Какие должны быть пределы макросов? Я мог бы предположить, что Rust, желая сократить время компиляции, хочет ограничить оценку времени компиляции (и особенно избежать бесконечных циклов). Racket использует подход «башни составителей и расширителей» с фазами, как указано в Lisp in Small Pieces. Хотим ли мы разрешить такие вещи, как разрешение доступа к API времени компиляции для выполнения файлового ввода-вывода и ограниченных рекурсивных вычислений? Должны ли мы позволить вещам вроде процедурных макросов превращать спецификации электронной таблицы CSV в операторы переключения?

Я хотел бы услышать о других системах! Я слышал, что в Template Haskell есть интересный подход с четко определенными типами для представления их AST, а лень в Haskell может заменить многие применения макросов для управляющих структур.

Извините, если я выхожу из строя.

Какие должны быть пределы макросов?

Для процедурных макросов, обсуждаемых в этом выпуске, нет . Процедурный макрос - это расширение компилятора. Он может взять немного кода C ++, запустить его через clang и добавить полученный объект в компиляцию. Может потребоваться некоторый SQL, запрос к базе данных, чтобы найти соответствующий тип результата и сгенерировать соответствующий набор результатов. Это реальные варианты использования, которые люди хотят использовать!

Обратите внимание, что в Rust есть другая макросистема. Это обновление было одобрено как RFC 1584, а реализация отслеживается https://github.com/rust-lang/rust/issues/39412.

@VermillionAzure , быстро взглянув на формы схемы, на которые вы ссылались:

macro_rules и их обновление согласно RFC 1584 аналогичны syntax-rules . Если у вас есть предложения по их улучшению, https://github.com/rust-lang/rust/issues/39412 , вероятно, лучшее место для обсуждения этого.

Макросы proc, относящиеся к этой проблеме, похожи на общую форму 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 уместной идеей для добавления в обсуждение - очевидно, что, поскольку процедурные макросы должны быть намного более мощными, чем макросистема syntax-case в Scheme, это тривиально для реализации всех макросистем с точки зрения произвольной мощности, представленной здесь.

@ jan-hudec Разумно ли разрешать любые произвольные вычисления в качестве расширения компилятора без каких-либо гарантий безопасности? Я абсолютно поражен идеей, что процедурные макросы будут здесь настолько мощными, но могут ли потенциальные пользователи Rust считать это недостатком использования пакетов? Я ни в коем случае не эксперт по безопасности, но нельзя ли использовать уязвимости в каких-либо библиотеках, которые используются в расширениях компилятора, для злонамеренного превращения компилятора Rust в вектор атаки? Кроме того, если в библиотеках, используемых в процедурных макросах, возникают какие-либо ошибки (например, segfault, вызванный неправильным кодом библиотеки C), означает ли это, что segfault просочится и приведет к сбою компилятора без надлежащего обмена сообщениями об ошибках?

Будет ли способ инкапсулировать ошибки, возникающие в процедурных макросах, таким образом, чтобы они не влияли на другие части компилятора?

Еще одна идея: когда выполняются процедурные макросы? Если процедурные макросы могут взаимодействовать с кодом, который имеет побочные эффекты, которые могут иметь значение (например, связь с внешним сервером с отслеживанием состояния, изменение внешней базы данных SQL, получение ключа безопасности для входа во внешнюю систему), то это не означает, что порядок, в котором процедурные макросы запускаются в процессе компиляции, важен?

Пакеты @VermillionAzure Cargo уже могут иметь сценарии сборки, которые выполняют произвольный код во время компиляции, поэтому процедурные макросы не ухудшают ситуацию на этом фронте: вам уже нужно доверять своим зависимостям. (Это несколько упрощается тем, что crates.io является неизменяемым / доступным только для добавления, а зависимости не обновляются автоматически, если у вас есть файл Cargo.lock : вам нужно доверять только определенным версиям.) И даже если сценарии сборки этого не сделали. существуют, ваши зависимости по своей природе могут выполнять произвольный код во время выполнения. Время компиляции намного хуже?

Это обсуждение заставляет меня задуматься о связанной, но другой проблеме.

Предположим, что ящик определяет два макроса proc: foo!() записывает временный файл, а bar!() читает тот же файл. Потребитель этого ящика вызывает как foo!() и bar!() в одном и том же модуле. Затем успешность компиляции будет зависеть от того, какой из foo!() или bar!() раскрывается первым. Этот порядок определяется реализацией, и, если достаточно людей напишет такой код, он может стать стандартом де-факто.

Я не уверен, насколько это серьезная проблема. Просто обеспокоен тем, приведет ли это к повторению махинаций с упорядочением полей структуры.

@SimonSapin

Хотя я согласен с вашей позицией, я должен указать, что есть одно существенное различие между выполнением во время компиляции и выполнением во время выполнения:

Он обеспечивает другую модель угроз, поскольку все обычно компилируется один раз, а затем развертывается на многих машинах. (например, использование невнимательности сопровождающего плюс недостаток изолированности в кластере сборки дистрибутива Linux.)

@lfairy Да, это именно та проблема, с которой Racket столкнулась более десяти лет назад, в 2002 году. Мэтью Флэтт, самый крупный участник Racket, «Составные и компилируемые макросы: когда это нужно Р. Кент Дибвиг, кто работал над Chez Scheme, также написал статью о фазах оценки для библиотек / модулей в «Неявное фазирование в библиотеках R6RS» .

@SimonSapin Время компиляции потенциально может быть намного хуже. Если ваш компилятор дает сбой в случайном порядке или выполняет вредоносное поведение, которое запускается компилятором, я готов поспорить, что кто-то в конечном итоге напишет огромный пост Reddit под названием «Модули Rust по своей природе небезопасны» или что-то в этом роде.

@VermillionAzure , я не очень внимательно читал статьи, но я не думаю, что они актуальны для обсуждения, поскольку проблемы, с которыми сталкивается Rust, сильно отличаются от проблем, с которыми сталкивается Scheme.

В схеме одна библиотека может предоставлять как функции, так и макросы, поэтому компилятор должен правильно определить, какие функции ему нужны во время компиляции, а какие - во время выполнения. Однако в Rust ящик предоставляет либо процедурные макросы, либо функции времени выполнения, так что это разделение (на данный момент) очевидно.

(Обратите внимание, что ящик, предоставляющий функции времени выполнения, также может предоставлять основанные на правилах (гигиенические) макросы, но это отдельный механизм в Rust)

Проблема, о которой говорит

@ jan-hudec Да, думаю, ты прав. Но порядок оценки определенно будет иметь значение, если побочные эффекты разрешены во время компиляции, если вы не можете гарантировать, что определенный модуль не вызывает побочных эффектов. Может ли модуль типизироваться?

Я думаю, что процедурный макрос «вероятно, не должен» иметь побочных эффектов, потому что на некоторые детали (см. Ниже) нельзя полагаться, но у нас, скорее всего, не будет механизма, подобного системе типов, в языке, чтобы заставить их быть чисто функциональный.

Эти сведения включают в себя порядок выполнения и параллелизм по сравнению с другими макросами proc, а также повторное выполнение макроса proc в инкрементной сборке. Для последнего мы можем захотеть добавить что-то для объявления зависимостей, подобное rerun-if-changed в сценариях сборки. И, как и в сценарии сборки, эти объявления могут быть неполными или содержать ошибки. Мы не можем статически предотвратить все ошибки.

Я думаю, нам следует избегать каких-либо гарантий в отношении побочных эффектов (например, ящикам макросов proc не разрешается полагаться на работу побочных эффектов, и им не разрешается полагаться на повторный запуск для чего-либо, кроме изменения кода в модуле, в котором они применяются ( Итак, нет глобального состояния).

Позже мы можем ослабить это требование, указав повторный запуск при изменении и другие параметры.

(У меня есть наполовину готовый общий сценарий сборки / предложение по безопасности макросов для процедур, которое здесь немного поможет, но я еще не написал его)

Макросы IMO proc / custom derive должны быть помещены в изолированную среду без какого-либо ввода-вывода или другого подключения к внешнему и оцениваться miri, возможно, с JIT кранлифта.

@ est31 отличная идея, но вроде дизельного топлива infer_schema! уже
существует, bindgen необходимо читать файлы и запускать программы, даже include! а также
env! использовать ввод / вывод.

9 ноября 2017 г. в 06:19 "est31" [email protected] написал:

Макросы IMO proc / custom derive должны быть помещены в изолированную среду
без какого-либо ввода / вывода или другого подключения к внешней стороне и оцениваться
Мири, может быть, с кранлифтом JIT.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/rust-lang/rust/issues/38356#issuecomment-343124957 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAC3n5VOPdKBsu81Sp3tp2XlIQ05L865ks5s0t_PgaJpZM4LMWlc
.

Похоже, что # 40939 и # 44528 уже объединены ... @jseyfried, не могли бы вы обновить контрольный список?

@ mark-im обновлено.

Могут ли процедурные макросы генерировать процедурные макросы?

@VermillionAzure Я не пробовал, но не вижу причины, по которой они не могли. Конечно, как и макросы proc, генерирующие "исполняемый" код, они должны быть в ящиках отдельно от тех, в которых они используются.

Синхронно мы столкнулись с ограничением proc_macro :: TokenNode сегодня - разделители блоков { ... } связаны только с одним Span во входном TokenStream, поэтому нет возможности запустить ошибка, указывающая только на закрывающую } . Rustc, похоже, не имеет этого ограничения.

mod m {
    type T =
}

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

Лучшее, что мы можем сделать в макросе proc, - это указать на последний токен внутри блока, указать на весь блок или указать на следующий токен после блока, что на самом деле не является тем, что вам нужно для ошибки, подобной выше.

Общим решением было бы, чтобы Span::start и Span::end возвращали односимвольный Span вместо LineColumn как они это делают в настоящее время, а затем предоставляли способ перейти от Span к первой строке / столбцу диапазона.

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

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

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

Упоминание @abonander, который добавил этот API в # 43604.

имеют Span :: start и Span :: end возвращают 1-символьный Span вместо LineColumn, как в настоящее время, а затем предоставляют способ перехода от 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() и определяю MySend в main.rs, чего я и ожидал. Однако не удалось заставить его работать с def_site() .

#![feature(proc_macro)]

extern crate proc_macro;

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

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

#![feature(proc_macro)]

extern crate mac;

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

fn main() {}

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

Отслеживание этого на стороне 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? Это работает намеренно или случайно?

• Что еще в области действия может использоваться моими токенами def_site() , например Send ?

• Если MySend должен быть получен из библиотеки (например, представьте, что мы получаем serde::Serialize ), то конечному пользователю по-прежнему требуется serde в их Cargo.toml, даже если мы этого не сделаем. нужно, чтобы они написали extern crate serde . Можно ли сделать extern crate с помощью разрешения def_site() идент против файла Cargo.toml процедурного макроса и extern crate с разрешением call_site() идент против нисходящего потока Cargo.toml?

Что касается ящиков extern, я предполагаю, что ящики должны быть явно доступны для фазы 1 с помощью макроса proc.

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

@dtolnay

В коде в моем предыдущем комментарии, если я изменю impl_mysend_for, чтобы сгенерировать impl для Send вместо MySend, тогда все компилируется. К какому посылу относится это разрешение и почему он не попадает в различие между фазой 0 и фазой 1? Это работает намеренно или случайно?

Хороший вопрос. Прямо сейчас прелюдия находится в области действия на сайте определения (если только ящик proc-macro не #![no_implicit_prelude] ), и это случайность (в некотором смысле) из-за различия фазы 0 и фазы 1, как вы указываете .

Однако для эргономики я думаю, что фаза 1 должна неявно содержать std в корне макроса процедуры (чтобы вы всегда могли quote!(use std::...); ) и прелюдию для удобства / эргономики, и поскольку они уже неявны в фазе 0. Скоро на фазе 1 будет предложено добавить std в корень.

Что еще в области видимости может использоваться моими токенами def_site (), например Send?

Помимо прелюдии и (скоро) std как обсуждалось выше, единственными другими вещами в области действия на этапе 1 являются сами макросы proc (а не функции макроса proc, которые являются этапом 0).

Например,

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

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

Можно ли сделать extern crate с помощью идентификатора def_site () для разрешения процедурного макроса Cargo.toml и extern crate с идентификатором call_site () для сопоставления с исходным Cargo.toml?

Да, за исключением того, что я считаю, что внешний ящик с Span::def_site() должен разрешаться в отношении зависимостей фазы 1 (цели) процедурного макроса Cargo.toml - сегодняшние зависимости фазы 0 связаны с библиотеками, скомпилированными для платформы хоста . Поскольку зависимости фазы 1 еще не существуют, имя внешнего контейнера разрешается негигиенично, что, как вы отметили, раздражает.

Когда у нас есть зависимости фазы 1, нам не нужно будет указывать extern crate s в каждом расширении для начала, так что это не будет проблемой. Однако мы все равно должны это исправить - текущий план состоит в том, чтобы сначала попытаться разрешить целевые зависимости контейнера proc-macro, а затем вернуться к антисанитарному разрешению с циклом предупреждения с низким приоритетом, чтобы избежать оттока.

Что касается ящиков extern, я предполагаю, что ящики должны быть явно доступны для фазы 1 с помощью макроса proc.
#[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 автоматически попадают в область видимости корня ящика proc-macro в фазе 1.

В своем коде я обнаружил, что использую промежутки для двух целей: для управления разрешением имен и для управления сообщениями об ошибках. Связаны ли эти два элемента неразрывно, или можно было бы создать диапазон, который смешивает аспект разрешения имен одного диапазона с местоположениями сообщений об ошибках строки / столбца другого диапазона? Я ожидаю, что это будет обычная потребность.

Чтобы быть более конкретным, у меня есть признак, внесенный в область видимости в def_site моего настраиваемого производного объекта, и я хочу вызвать методы признаков в полях структуры пользователя. Если тип поля не реализует правильную характеристику, я хочу, чтобы сообщение об ошибке подчеркивало соответствующее поле структуры.

Я могу сгенерировать вызов метода с диапазоном def_site, который компилируется и запускается, но сообщения об ошибках, к сожалению, всегда указывают на атрибут derive, как мы видели в Macros 1.1.

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

Или я могу сгенерировать вызов метода с тем же диапазоном, что и идентификатор или тип поля структуры, который показывает правильное подчеркивание, но не может разрешить черту в области на моем def_site.

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

Как правильно разрешить и показать ошибки так, как я хочу?

@dtolnay Отличный момент, спасибо.

Я думаю, что правильный способ исправить https://github.com/rust-lang/rust/issues/46489 может состоять в том, чтобы сделать так, чтобы сгенерированные токены #[derive(…)] имели интервалы разрешения имен в одном и том же scope как определение типа, а интервалы сообщений об ошибках при вызове макроса quote! {} который их создал.

Как обстоят дела с гигиеной сейчас? У меня есть функция, подобная процедурному макросу, которая работала (4 месяца назад), но начиная с rustc 1.24.0-nightly (b65f0bedd 2018-01-01) он жалуется, что аргумент не может быть найден в области видимости.

Извините, мне следовало сначала поискать в системе отслеживания проблем, похоже, я только что нажал на https://github.com/rust-lang/rust/issues/46489.

Я подал № 47311, который, как мне кажется, в настоящее время блокирует правильную реализацию derive (Deserialize). Процедурные макросы не могут создать структуру с частными полями.

Подан другой, # 47312, в котором доступ к безымянному полю структуры кортежа, например self.0 имеет другие требования к диапазону токена . чем доступ к именованному полю структуры, например self.x .

47311 и # 47312 зафиксированы в # 48082 и # 48083 соответственно.

У меня есть два вышеупомянутых PR, ожидающих обзора / комментария.

Похоже, https://github.com/rust-lang/rust/pull/41029 готов?

Этот PR был заброшен, но возрожден и продолжает работать в # 48465. В настоящее время ждем на Кратере.

@petrochenkov @nrc

Глядя на syntax::ext::expand , кажется, что proc_macro_attribute s в настоящее время не обрабатываются в нескольких контекстах (не исчерпывающий):

• на блоках ( fold_block() - нет)
• по операторам / выражениям (# 41475, # 43988)
• внутри extern {} блоков (# 48747)

RFC 1566 не перечисляет конкретные типы узлов AST, к которым могут применяться макросы атрибутов, предполагая, что они должны быть применимы практически ко всему. Но это может показаться немного смешным, поэтому мы должны четко определить, что нужно обрабатывать, а что нет, и где атрибуты никогда не должны быть разрешены, но в настоящее время могут быть (# 43988)

@abonander намерение состоит в том, что атрибуты макроса proc могут использоваться везде, где может быть обычный атрибут, и нигде больше, что, я думаю, охватывает все вышеперечисленное (хотя некоторые из них нестабильны, и если мы стабилизируем макросы proc, мы должны быть осторожны, чтобы только стабилизировать использование, которое стабильно для других атрибутов).

@nrc есть где-нибудь, где перечисляются эти местоположения, потому что ссылка только говорит, что атрибуты могут быть применены к любому элементу . Однако я почти уверен, что атрибуты lint также могут применяться к блокам и операторам.

@nrc есть где-нибудь, где перечисляются эти местоположения, потому что ссылка только говорит, что атрибуты могут быть применены к любому элементу. Однако я почти уверен, что атрибуты lint также могут применяться к блокам и операторам.

Нет afaik - есть принятый RFC и флаг нестабильной функции для атрибутов в любом выражении, но я думаю, что мы стабилизировали только операторы и блоки. По ссылке нет данных.

Эта проблема:

Макросы проверки стабильности (proc-) (issue # 34079).

Сейчас закрыты прок-макросы WRT. Мой PR просто не добавил проверку стабильности для макросов Macros 2.0, поэтому проблема все еще открыта (хотя, скорее всего, это просто новая проблема).

@rfcbot fcp слияние

Я хотел бы предложить стабилизировать подмножество макросов 2.0 story в виде макросов 1.2 для выпуска Rust 1.28. Rust 1.28 выходит каждую ночь 10 мая 2018 года (~ 2,5 недели с момента написания этой статьи) и станет стабильным 2 августа 2018 года. Я думаю, что FCP может закончиться до 10 мая, когда 1.27 войдет в бета-версию, но я бы хотел подождать. отключите здесь любые стабилизации до тех пор, пока не произойдет отключение, и отложите это до выпуска 1.28.

Это недавно обсуждалось на внутреннем уровне вместе с рядом проблем, зарегистрированных @petrochenkov и которые должны быть исправлены сейчас (но еще не выпущены в ночное время). Я думаю, было бы полезно подвести итоги здесь, так что это именно то подмножество, которое будет стабилизировано.

Однако помните, что это подмножество . Отсутствие здесь функциональности не означает, что она никогда не будет стабилизирована или удалена из компилятора. Скорее, эта функциональность останется нестабильной после этого предложенного этапа стабилизации, который будет стабилизирован позднее.

use some_proc_macro_crate::bar;

#[bar]
fn baz() {}

use some_proc_macro_crate::bar;
bar!();

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

extern crate proc_macro;
use proc_macro::TokenStream;

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

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

pub struct TokenStream(_);

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

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

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

pub mod token_stream {
    pub struct IntoIter(_);

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

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

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

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

pub struct Span(_);

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

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

pub struct Group(_);

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

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

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

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

pub struct Term(_);

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

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

pub struct Op(_);

pub enum Spacing {
   Alone,
   Joint,
}

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

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

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

pub struct Literal(_);

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

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

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

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

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

Член команды @alexcrichton предложил объединить это. Следующий шаг - проверка остальными отмеченными командами:

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

В настоящее время не перечислено никаких проблем.

Как только большинство рецензентов одобрит (и никто не возражает), наступит последний период для комментариев. Если вы заметили серьезную проблему, которая не поднималась ни на одном этапе этого процесса, сообщите об этом!

См. Этот документ для получения информации о том, какие команды могут давать мне члены команды, отмеченные тегами.

cc @ rust-lang / compiler, я знаю, что вы тоже очень заинтересованы в этом, и, пожалуйста, не стесняйтесь высказывать любые возражения. Если у вас есть возражение по поводу блокировки, я также могу зарегистрировать его для вас

Похоже, что, используя предоставленный API, предложенный для стабилизации, макросы proc могут легко генерировать всевозможные токены или копировать их из ввода в вывод, но не могут легко проверить поток токенов даже на поверхностном уровне. Например, Literal не реализует Eq или PartialEq . Какая-то конкретная причина для этого? (И даже это позволило бы сравнить только с указанными постоянными значениями, а не извлекать значение и обрабатывать его в коде.)

Что может сделать макрос proc для интроспекции литерала внутри реализации макроса proc, учитывая TokenStream ? Или, если на то пошло, извлечь ценность одного? Это просто еще не поддерживается? Есть ли планы по его поддержке в будущем?

(Я не пытаюсь блокировать стабилизацию предложенного подмножества; я просто хотел бы лучше понять это подмножество и его предполагаемые функции.)

@alexcrichton Новинки будут иметь такую ​​же гигиену, как и macro_rules! делает сегодня. Они будут
не быть гигиеничным. Новые элементы, добавленные в AST, войдут в то же пространство имен, что и
другие элементы в модуле.

Я не являюсь членом основной команды Rust, и я не изучал подробно все предыдущие обсуждения, но для меня это звучит очень плохо. Что, если макрос хочет сгенерировать вспомогательные элементы, к которым может получить доступ только макрос?

Вместо того, чтобы отказываться от гигиены, я думаю, что лучше обеспечить полную 100% гигиену, но предоставить макросам возможность явно отказаться от соблюдения гигиены для определенной переменной.

@joshtriplett вы бы использовали Display impl для Literal.

@joshtriplett да, поскольку @dtolnay упомянул, что вы должны использовать Display котором построен ящик, такой как literalext . В общем, API задуман как «минимум», а не как первоклассный API, в котором есть все навороты. Скорее всего, они появятся позже!

Предполагается, что этот раунд стабилизации будет «максимально минимальным» в том смысле, что он обеспечивает наименьший объем функциональности для покрытия всех вариантов использования (также известный как Display для Literal и ничего больше для его интерпретации. ).

@Pauan, это не здорово, да, но это то же самое, что и macro_rules! которое уже много лет стабильно и работает во многих разных контекстах. Мы хотим обеспечить здесь гигиену и лучшее лечение, но еще не совсем готовы. Конструктор Span::call_site() - это стержень здесь, где, используя его, вы запрашиваете «отсутствие гигиены». В конце концов мы стабилизируем больше вариантов.

К сожалению, до "полной 100% гигиены" еще далеко, и цель этого предложения - получить что-то стабильное для Rust 2018.

@alexcrichton Так есть ли план стабилизировать это сейчас с помощью гигиенической дыры, а затем пару эпох / эпох / выпусков исправить эту гигиеническую дыру?

Поскольку Span::call_site() существует, есть ли причина, по которой он не может иметь полную гигиену прямо сейчас? Это нехватка рабочей силы / времени или есть теоретические / семантические проблемы, которые все еще необходимо конкретизировать в RFC?

@Pauan, чтобы повторить, нет настоящей "дыры" в том смысле, что она уже существует сегодня. Это точно такая же гигиеническая история с macro_rules! и custom derive. Это предложение, по сути, является продолжением этого, а не вводит ничего нового.

Учитывая "идеальную историю гигиены", мы всегда хотим отказаться от какой-либо формы. В настоящее время этот отказ составляет Span::call_site() (фактически). Только стабилизируя это, мы только стабилизируем механизм отказа для гигиены. Со временем мы стабилизируем больше функциональных возможностей, чтобы при необходимости предметы были полностью гигиеничными.

Стабилизация гигиены намного дальше. Есть (AFAIK) нерешенные исследовательские вопросы, это не вопрос людских ресурсов.

@dtolnay А, понятно. Итак, вы генерируете текст, а затем повторно анализируете его? Я полагаю, что на данный момент это работает.

cc @ rust-lang / compiler, я знаю, что вы тоже очень заинтересованы в этом, и, пожалуйста, не стесняйтесь высказывать любые возражения. Если у вас есть возражение по поводу блокировки, я также могу зарегистрировать его для вас

У меня все еще есть кое-что для обзора и PR с парочкой настроек API-интерфейса proc-macro.

Это точно такая же история гигиены с macro_rules! и обычай получать.

Конечно, но я думал, что одна из целей заключалась в том, чтобы сделать лучшую макросистему, поэтому указание на существующую (сломанную и ограниченную) систему мне не очень убедительно.

Учитывая "идеальную историю гигиены", мы всегда хотим отказаться от какой-либо формы.

Совершенно верно, но я хочу сказать, что, поскольку можно использовать Span::call_site() для нарушения гигиены (и, таким образом, получить функциональность macro_rules! ) при желании, сделав его гигиеничным по умолчанию, вы получите доступ как к гигиене, так и отсутствие гигиены. В то время как если он стабилизируется за счет отсутствия гигиены, то он застревает только за счет отсутствия гигиены.

Со временем мы стабилизируем больше функциональных возможностей, чтобы при необходимости предметы были полностью гигиеничными.

Это звучит как довольно раздражающий (и сбивающий с толку) лейкопластырь: макросы proc будут гигиеничными в большинстве ситуаций (но не для предметов), но затем вы можете использовать новую функцию, чтобы включить гигиену для предметов. Я правильно понимаю?

Есть (AFAIK) нерешенные исследовательские вопросы, это не вопрос людских ресурсов.

Ладно, это справедливо. Понимаю стремление к целесообразности и прагматизму. До тех пор, пока план состоит в том, чтобы в конечном итоге иметь твердую гигиену по умолчанию в более позднюю эпоху / эпоху / издание, тогда я в порядке с временной плохой гигиеной. Я просто не хочу, чтобы мы стабилизировали то, о чем позже пожалеем.

В некотором смысле, это уже «гигиенический по умолчанию» это просто , что по умолчанию пока не поддерживается. Span::call_site - это отказ. :)

@Pauan Чтобы уточнить, что сказал @alexcrichton :

Для построения идентификатора требуется Span , содержащий гигиеническую информацию. (См. Term::new )

В будущем мы можем предложить множество различных способов построения Span s, которые отражают различные варианты гигиены. Но пока мы будем отображать только Span::call_site который принимает область действия вызывающего.

Таким образом, мы можем избежать стабилизации всей системы гигиены сразу, сохраняя при этом возможность добавить гигиены позже. Я думаю, что это довольно хитрый прием, чтобы обойти проблему!

@rpjohnst Значит, вы имеете в виду, что единственный способ вернуть новые элементы из макроса proc - использовать Span::call_site ?

Если это так, то это звучит идеально: в этом случае гигиена действительно может быть добавлена ​​в будущем чистым и обратно совместимым способом.

@lfairy Аааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа действаьаааааааааааареда необходимо использовать Span::call_site , я думал, что это негигиеничная область действия по умолчанию. Спасибо вам за разъяснение! Вы правы, это очень хитрый трюк.

Таким образом, у меня больше нет возражений.

@alexcrichton

Атрибуты, макро_правила и процедурные
все макросы находятся в пространстве имен maro.

В последний раз я проверял с помощью #[feature(proc_macro)] , у него было обратно несовместимое изменение в стабильном коде для ящика derive-error-chain, как описано здесь. Из процитированного заявления похоже, что так будет и в макросах 1.2. Это верно?

@Arnavion Боже #[derive] .

Похоже, что # 48644 и # 47786 готовы. Может кто-нибудь обновить ОП?

@alexcrichton Обсуждалось ли разрешение доступа к внутренним данным Literal и его друзьям? Я понимаю, что они больше не перечисления по причинам обратной совместимости, но есть ли причина, по которой у нас не может быть чего-то вроде этого для начала с Literal :

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

Мы могли бы даже иметь кучу TryFrom impls для различных подтипов литералов.

@abonander, это обсуждалось, да, но было Display и у нас есть место для добавления позже в будущем.

: bell: Сейчас наступает последний период для комментариев , как указано в обзоре выше . : звонок:

@alexcrichton
!Send и !Sync impls для типов API макросов proc не записываются явно, но предполагаются.
Для некоторых структур (например, Op ) предполагаемый impl отличается от того, что указано в https://github.com/rust-lang/rust/issues/38356#issuecomment -383693017.
Вероятно, имеет смысл явно добавить импы.

Ой, да, действительно! Я открыл https://github.com/rust-lang/rust/pull/50453, чтобы решить эту проблему.

@alexcrichton У нас неприятная проблема с Term::as_str : я пытался набросать неофициальное доказательство того, что из-за строгой области видимости &'a Term -> &'a str может быть реализовано для заимствования у какого-то интернера с ограниченной областью видимости, а 'a никогда не может быть больше, чем область действия самого интернера (что имеет значение только в том случае, если функция завершается успешно, т.е. если она вызывается в той области, в которой интернер находится в рабочем состоянии).

AFAICT, Term::as_str является правильным , но только при условии, что условие 'a .

Что подтверждается, например, thread_local! , потому что, хотя он позволяет вам избежать значения Term , он дает вам очень недолговечные 'a s, что, если Term::as_str success, строго короче, чем внутренняя область видимости.
В общем, как происходит расширение 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! ? rustc говорит мне} ,

@mjbshaw ооочень забавную историю: она реализована в proc_macro::quote .
rustc_metadata делает вид, что любой ящик с именем proc_macro содержит в себе процедурный макрос с именем quote , но используемая реализация взята из proc_macro rustc_metadata ссылки против.

У меня все еще есть кое-что для обзора и PR с парочкой настроек API-интерфейса proc-macro.

Обзорный PR: https://github.com/rust-lang/rust/pull/50473

Запрос функции для API 1.2: добавьте разделитель для угловых скобок ( < / > ), чтобы такие вещи, как <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, но у нас есть то, что мне кажется двумя возможными ошибками showstopper, связанными с гигиеной, в зависимости от того, как они обнаруживаются:

• Гигиена - это странно
• Гигиена еще более странная

Для тех, кто следит за этой веткой, API, вероятно, будет изменен из исходного комментария FCP в https://github.com/rust-lang/rust/pull/50473, предложенного @petrochenkov. Резюме на данный момент таково:

• Переименуйте Term::new в Term::ident и проверьте ввод.
• Добавьте Term::lifetime и проверьте ввод
• Добавьте Term::raw_ident и подтвердите ввод
• Переименуйте Op в Punct
• Проверить ввод на Punct::new
• Переименуйте Op::op в Punct::as_char

Один небольшой запрос API, который я бы сделал (возможно, в # 50473 - @petrochenkov), - это какой-то способ добавить токены в TokenStream. Возможно:

impl Extend<TokenTree> for TokenStream

Я считаю, что это позволило бы устранить тип quote::Tokens (который в основном представляет собой Vec<TokenTree> ) и уменьшить распространение различных типов в экосистеме, которые все означают «некоторые токены», отслеживаемые в https : //github.com/dtolnay/syn/issues/205.

+1 к предложению @ dtolnay выше.

Последний период комментариев с предложением о слиянии в соответствии с приведенным выше обзором завершен .

У меня два вопроса:

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 макрос quote! в ящике proc_macro не стабилизируется как часть этого FCP, но ящик quote на crates.io основан на предлагаемом здесь API. Также, как указал @abonander , макросы атрибутов объявляются с #[proc_macro_attribute] а #[proc_macro] зарезервировано исключительно для макросов foo!() -style.

Разве #[proc_macro_attribute] следует называть #[proc_attribute_macro] или #[attribute_proc_macro] ?

@Zoxc У нас уже есть #[proc_macro_derive] stable, поэтому было бы странно не следовать этому для макросов атрибутов.

Можем ли мы получить PartialEq<char> и PartialEq<Punct> для Punct (аналогично реализации Ident PartialEq )? Похоже, добавить это будет довольно безопасно. Я счастлив написать PR, но не хочу, если идея не подходит.

@mjbshaw Будет ли PartialEq<Punct> также сравнивать промежутки? PartialEq<char> вроде нормально, OTOH.

@eddyb PartialEq для Ident не сравнивает промежутки (я знаю, что это источник proc-macro2, а не источник proc-macro). Я неоднозначно отношусь к тому, включены ли промежутки в сравнение, но я ожидаю, что Punct и Ident будут вести себя в этом отношении одинаково. Punct также имеет свой собственный Spacing , который, как я полагаю, будет включен в сравнение (хотя, возможно, другие думают иначе).

Я бы в порядке, реализовав на данный момент только PartialEq<char> за Punct . PartialEq<Punct> можно хешировать позже.

@mjbshaw ящик proc-macro2 может быть не таким, как proc_macro и дает нам некоторую свободу экспериментировать с различными настройками. Я подозреваю, что если он хорошо работает на crates.io, мы можем добавить его в proc_macro , но, конечно, он обратно совместим, чтобы добавить к proc_macro поэтому мы начинаем с самого минимума и мы сможем масштабироваться оттуда, как только он станет стабильным.

Я провел некоторую сортировку всех ошибок, связанных с макросами 1.2 . Большинство ошибок можно разделить на «серьезные ошибки» или «ошибки, связанные со всем диапазоном». В настоящее время ошибки, связанные с диапазоном, влияют только на сообщения об ошибках (поскольку макросы 1.2 не предназначены для изменения разрешения). Оставшаяся ошибка, не связанная с диапазоном (она же серьезная) - это https://github.com/rust-lang/rust/issues/50050 , для которой у @petrochenkov есть решение .

Класс Gnome сломался с изменениями в proc_macro2 / syn / quote, а также с воротами функций для генерации модулей из макросов proc. К счастью, теперь это исправлено.

За какими вещами я должен следить, чтобы быть в курсе изменений в этой маленькой экосистеме?

@federicomenquintero Если вы используете нестабильные функции, подумайте о том, чтобы иметь регулярное задание CI (ежедневно, еженедельно, независимо от того, что вам

@SimonSapin, спасибо, это хорошая идея. Мы закрепляем версии этих ящиков в нашем Cargo.toml, но, возможно, пришло время удалить номера версий и просто позволить Cargo загрузить последнюю. Это правильный способ сделать это?

@federicomenquintero Это все больше не по теме, поэтому, если вы хотите продолжить это обсуждение, сделайте это где-нибудь в другом месте, например, в IRC или http://users.rust-lang.org/ , но общая рекомендация заключается в том, чтобы приложения (как в отличие от библиотек) должны отправлять Cargo.lock вместе со своим исходным кодом, который эффективно связывает зависимости. В Cargo.toml рекомендуется объявить зависимость типа foo = "1.2.3" , это неявно означает «эта версия или более поздняя, ​​если она совместима согласно SemVer».

Итак, я только что столкнулся с проблемой процедурных макросов, которая мешает мне разработать ящик, который я хочу сделать.

Учтите следующее:

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

В настоящее время это не работает, потому что обе функции proc_macro и custom_attributes требуются, но не могут использоваться одновременно. Насколько я понимаю, стабилизация макросов proc избавит от необходимости использовать флаги функций?

Другое дело, что таким образом #[my_attribute] потенциально может сгенерировать код, который предотвращает запуск #[other_attribute] . Что было бы действительно круто, если бы во «внешнем» атрибуте я мог зарегистрировать внутренние атрибуты, которые работают так же, как работают #[derive(Foo)] .

Что насчет комментария ?

Можно ли / желательно заменить эту панику неявным созданием фиктивного «сеанса»? Или, может быть, добавить публичный API (с путем к стабилизации) для его создания?

Думаю, было бы очень полезно провести фиктивную сессию. Написание модульного теста для ящиков proc-macro практически невозможно или, по крайней мере, очень неудобно в противном случае. Более того, это не только TokenStream::from_str , но и другие функции, требующие сеанса.

@alexcrichton

Я проделал некоторую сортировку всех ошибок, связанных с макросами 1.2. Большинство ошибок можно разделить на «серьезные ошибки» или «ошибки, связанные со всем диапазоном».

Я бы хотел обновить https://github.com/rust-lang/rust/issues/50504 до статуса «серьезный» - описанная проблема модуля является лишь признаком более глубокой проблемы - идентификаторы расширения для макросов proc не правильно зарегистрирован. Я не знаю, какие еще последствия это может иметь.
Есть PR, устраняющий основную проблему (https://github.com/rust-lang/rust/pull/51952), но есть отклонения от исправления, и я еще не просматривал их.

Я разместил PR для стабилизации большего количества процедурных макросов на https://github.com/rust-lang/rust/pull/52081

@petrochenkov мне

Я только что опубликовал сообщение о проблеме отслеживания имен макросов о проблемах с атрибутами proc_macro_derive child и о том, как они взаимодействуют с системой именования. Есть еще одна проблема, связанная с тем, как атрибуты proc_macro_derive child взаимодействуют с областью видимости и именованием, но, по-видимому, более уместна для обсуждения здесь. Поскольку пути в атрибутах в настоящее время не находятся на пути к стабилизации, мы получаем возможность того, что #[derive(foo::Parent)] может иметь дочерний атрибут #[foo::Child] , но макрос деривации не будет иметь возможности, на первый взгляд, для определить, действительно ли дочерний атрибут является его собственным дочерним элементом, поскольку он не может выполнять поиск по имени. На данный момент у меня нет простого решения, но я думаю, что это то, что должно быть в поле зрения будущего взаимозависимых атрибутов; нет причин, по которым атрибуты proc_macro_attribute не могли взаимодействовать таким образом, чтобы возникали аналогичные проблемы поиска.

Я пытался скомпилировать свой проект сегодня, но что-то сломалось, что, вероятно, связано с этой проблемой. Во всех сообщениях об ошибках было сообщение: «(см. Issue # 38356)». Вот как я сюда попал.
Я включаю сюда сообщение об ошибке, которое я получил во время компиляции. Я также включаю свой Cargo.toml.

Я нахожу это очень удивительным, поскольку мой проект привязан к определенной ночной версии Rust (rustc 1.29.0-nightly (9bd8458c9 2018-07-09)) Что могло измениться? Возможно обновилась библиотека?

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

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

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

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

capnp = "0.8"
rusqlite = "0.13"

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

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

[dev-dependencies]

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

[build-dependencies]
capnpc = "0.8"

[profile.release]
debug = true

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

error: aborting due to 63 previous errors

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

У вас есть представление о том, что могло пойти не так и как это исправить? Спасибо!

@realcr для proc-macro2 вы можете просто запустить cargo update и это должно помочь!

@alexcrichton Я не думаю, что здесь проблема. Я думаю, что @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_macro, из расширения процедурных макросов? (или любой другой ящик, известный из ящика proc_macro, FWIW)

Существуют обходные пути , но AFAIU не будут работать, если ящик будет переименован пользователем процедурного макроса.

Ящики @Ekleog proc-macro обычно компилируются только для создания ящиков, которые их используют. Они не являются зависимостями во время выполнения. Вы можете рассматривать весь ящик proc-macro как своего рода плагин компилятора, а не «обычную» библиотеку.

Это особенно заметно при кросс-компиляции: как и сценарии сборки, макросы proc компилируются для хост-платформы, а не для целевой.

@SimonSapin Я согласен с вами, но может быть действительно полезно делегировать часть работы функции, предоставляемой ящиком, даже если это не ящик proc-macro (например, в моей ссылке выше X-derive crate пытается использовать функцию из X crate). Потому что в противном случае это означало бы, что весь код, сгенерированный proc-макросами, должен быть либо самодостаточным, либо делать предположения о состоянии сайта вызова.

Затем я могу понять, что rustc еще не готов для такого рода функций (потому что я думаю, что это будет работать лучше без необходимости разделять proc-macro из ящиков, не связанных с proc-macro, что, похоже, где-то в долгосрочной перспективе. дорожная карта срока). Но мне интересно, если текущий интерфейс, использующий только TokenStreams будет стабилизирован, возможно ли будет модернизировать эту функцию позже? Разве ему не понадобится что-то вроде типа токена PathToBeResolvedFromTopOfGeneratingProcMacroCrate ? (что было бы критическим изменением, если бы оно было добавлено позже, afaiu)

Возможно, со временем удастся сделать вещи более гибкими, но это кажется довольно далеким.

А пока, если вы являетесь автором библиотеки, подумайте о том, чтобы иметь ящик foo-proc-macros или foo-derive для процедурных макросов и "нормальную" библиотеку foo , содержащую среду выполнения код, но также реэкспортирует процедурные макросы. Таким образом, API, ориентированный на пользователя, может храниться в одном ящике. Это то, что делает serde (в некоторых конфигурациях) https://github.com/serde-rs/serde/blob/v1.0.71/serde/src/lib.rs#L304

Однако стоит отметить, что этот обходной путь все еще не решает проблему переименования пользователем корневого ящика (например , проблему отслеживания 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 s, и каждый TokenTree связан с Span , который несет информацию об области видимости. За исключением того, что в настоящее время нет способа создать диапазон для любой другой области, кроме «call site» (или пустой). По сути, необходимо разработать достаточно эргономичный способ создания Span s, относящихся к конкретному ящику.

Причина, по которой я спросил, в том, что флажок не установлен. Было бы неплохо тогда поставить галочку!

Что осталось от этой проблемы после стабилизации #![feature(proc_macro)] ?

@ jan-hudec О, я думал, что Span s предназначены только для сообщений об ошибках, так как в ранних сообщениях в блогах упоминалась структура Hygiene (или одноименная), которая играла эту роль. Я предполагал, что они исчезли, и явно ошибался. Спасибо! :)

Что осталось от этой проблемы после стабилизации #! [Feature (proc_macro)]?

В идеале необходимо зарегистрировать свежие проблемы для всех отдельных оставшихся проблем, а не стабилизированных функций, а затем эту проблему можно закрыть (точно так же, как это было сделано для https://github.com/rust-lang/rust/issues/ 44660).

О, я думал, что Spans предназначены только для сообщений об ошибках, поскольку в ранних сообщениях в блогах упоминалась структура Hygiene (или с аналогичным названием), которая играла эту роль. Я предполагал, что они исчезли, и явно ошибался. Спасибо! :)

IIUC, пролеты - это основной способ отслеживания гигиенического контекста.

@ mark-im Вид. Они включают как информацию о местонахождении исходного кода (для сообщений / диагностики, обращенных к пользователю), так и синтаксический контекст (например, гигиеническую информацию).

Учитывая объем обсуждений / трафика, который получает эта проблема, имеет ли смысл переместить proc_macro_diagnostic в отдельную проблему отслеживания? Я также хотел бы выяснить, какие есть блокираторы для стабилизации этой функции, и посмотреть, сможем ли мы протолкнуть ее. Дизель его использует, и до сих пор это было здорово. Отсутствие этой функции в стабильной версии приводит к тому, что сообщество создает забавные обходные пути, такие как новейшая версия syn, использующая вместо нее compile_error! .

@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 - это не что иное, как дословный исходный код, за исключением ряда значений токенов, а не надоедливого текста.

Расширенный API для TokenStream (с TokenTree ) стабилен в версии 1.29. Импорт макросов, подобных функциям, будет стабильным в 1.30.

Кажется, что с rustc 1.30.0-nightly (63d51e89a 2018-09-28) больше невозможно пройти код внутри модуля в отдельном файле. Если вы обработаете mod module; , вы получите TokenStream содержащий mod module; , WYSIWYG.

Я понимаю, что это необходимо для сохранения интервалов, гигиены и согласованности с обрабатываемым кодом. Есть или будет возможность работать с содержимым модулей в отдельных файлах? Его отсутствие может сбивать с толку конечных пользователей, когда тривиальный рефакторинг организации модуля вызывает изменение поведения макроса.

Хорошо, эта проблема огромна и дошла до того, что я не думаю, что слишком полезно продолжать работу и отслеживать 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
Есть ли в этом проблема?

@XX
Такие податрибуты не обязательно должны быть особенностями языка?
В случае derive требуется регистрация настраиваемых атрибутов, поскольку макросы извлечения не могут удалять атрибуты из своих входных данных (входные данные неизменяемы).
Макросы атрибутов могут удалить #[other_attribute] s из его входных данных, поэтому они никогда не дойдут до разрешения имен и никогда не сообщат об ошибке «неразрешенный атрибут».

(Помимо классических устаревших нестабильных настраиваемых атрибутов, упомянутых в https://github.com/rust-lang/rust/issues/38356#issuecomment-397095541, теперь они совместимы с макросами proc.)

@petrochenkov Да, спасибо за разъяснения.