Rust: Проблема с отслеживанием макросов 1.1 (RFC # 1681)

Я обновил описание проблемы, добавив контрольный список того, что необходимо сделать. Скорее всего, это не исчерпывающий список, но, надеюсь, он поможет нам пройти 90% пути.

Хорошо, я собираюсь изучить это сегодня и посмотреть, как далеко я продвинулся.

cc https://github.com/rust-lang/rust/pull/35957 , реализация

Из # 35957: мы должны еще немного изменить имя ящика librustc_macro. В частности, это должен быть ящик-долгожитель, в котором будет все необходимое для всех авторов макросов, поэтому ограничение rustc_macro (что, на мой взгляд, по крайней мере) касается только идеи 1.1, кажется плохим. Раньше я хотел использовать для этого libmacro, но поскольку macro - зарезервированное слово (и мы можем захотеть использовать его в качестве ключевого слова в будущем), это невозможно. @cgswords и я использовали libproc_macro, и я думаю, что это неплохое имя, хотя я не на 100% доволен этим.

@nrc : Хорошо, мои мысли по

• extern crate macros; - коротко и мило, но может читаться как содержащий макросы, а не как вспомогательный код для их написания
• extern crate macro_runtime; - именно то, что написано на банке
• extern crate metarust; - напишите Rust о Rust для работы на Rust
• extern crate bikeshed; - с процедурными макросами вы можете получить любой цвет Rust, какой захотите!
• extern crate macrame; - звучит как "макрос make [r]"; возможно, лучше оставить для будущего «хорошего» API вместо необработанной библиотеки.

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

Чтобы было ясно, думаете ли вы, что сегодняшние macro_rules будут просто «макросами», то есть тем, что мы подразумеваем под макросами по умолчанию, в то время как вы должны квалифицировать «процедурные макросы»? Мне это кажется вполне разумным планом. И в этом мире я бы сказал, что libproc_macro лучше, чем libmacros .

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

Но да, я очень хочу оторваться от терминологии «процедурного макроса».

@nrc Имеет смысл для меня! Хотя «макросы на примере» немного громоздок, это также очень запоминающийся / интуитивно понятный термин. Единственное, что меня беспокоит по поводу «процедурных макросов», так это то, что «процедура» не входит в состав Rust. Интересно, есть ли способ сделать связь более прямой. «Функциональный макрос» не совсем правильный, но, может быть, вы понимаете, что я имею в виду?

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

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

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

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

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

Меня устраивает libproc_macro или libmacros . Я предпочитаю последнее просто потому, что мне не нравится, когда в именах ящиков есть _ когда этого легко избежать. знак равно

Один вопрос: ожидаем ли мы когда-нибудь наличия «подпрограмм поддержки», которые можно было бы использовать из непроцедурных макросов? Я не знаю таких планов, но если бы мы это сделали и хотели бы, чтобы они были в одном ящике, тогда libmacros было бы лучшим названием. знак равно

(Я немного думаю, например, о комментарии @dherman из RFC с нетерпением

@nikomatsakis : Связанный, но несколько другой вопрос - это вариант использования, который я поднял в https://github.com/rust-lang/rfcs/pull/1561#discussion_r60459479 - хотим ли мы, чтобы функции реализации процедурных макросов могли вызывать другие функции реализации процедурных макросов?

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

Но да, я думаю, что пример gensym @dherman довольно убедителен. Конечно, если ответ на мой вопрос выше - «да», gensym является одновременно макросом (который может использоваться макросами в примерах) и функцией поддержки (которая может использоваться процедурными макросами).

У меня есть PR по грузам https://github.com/rust-lang/cargo/pull/3064, в котором должны быть отмечены все флажки "интеграция груза" в контрольном списке.

Я оставил комментарий к PR груза, но я думаю, что нам нужен другой тип _dependency_, а не просто другой тип _package_. Во-первых, я думаю, что это просто лучше эстетически и эргономично, но это только мое мнение. Но у меня тоже есть две конкретные причины.

• В будущем с публичными и частными департаментами важно знать, что публичные департаменты процедурных и обычные публичные депеши могут не совпадать. Например
• В будущем со встроенными процедурными макросами / квази-кавычками любая библиотека может использоваться во время компиляции.
• > хотим ли мы, чтобы функции реализации процедурных макросов могли вызывать функции реализации других процедурных макросов?

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

Серде работает?

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

(кроме атрибутов контейнера в некоторых случаях # 36211)

Отлично, спасибо за обновления @dtolnay!

Есть ли документация по этим макросам? Полагаю, единственный пример их использования - в серде, верно?

ОК, груз прибыл. Это нормально, но было бы неплохо вернуться к https://github.com/rust-lang/rust/issues/35900#issuecomment -243976887 перед стабилизацией. [Как бы то ни было, я хотел упомянуть об этом в исходном RFC, но забыл.]

Я думаю, что «макросы по примеру» и «процедурные макросы» можно было бы лучше разделить на «декларативные макросы» и «императивные макросы» соответственно. Это дает информативные параллели с более широко известной декларативной / императивной категоризацией языков программирования. Поскольку императив рассматривается как надмножество или синоним процедурного, он должен быть достаточно близок, чтобы люди, использующие терминологию «процедурного макроса», могли совершить прыжок. Также следует избегать путаницы с концепциями процедуры / функции / метода в самом ржавчине.
Эта схема именования дает нам ящик macro_imp и модуль для параллельного macro_rules . macro_rules конечном итоге может стать модулем более общего ящика macro_dec .

@nrc , когда вы говорите о "фактических плагинах", включаете ли вы такие вещи, как metacollect и clippy , такие вещи, как rustw , rustfmt и сервер языка Rust , или какую-то другую категорию программ?

Как бы то ни было, мне мягко не нравится название "по примеру" (поскольку в моем понимании шаблоны $foo не являются "примерами"). Для меня декларативное и императивное звучит лучше.

Играя с этим, я заметил одну проблему. Похоже, что предоставленные Rust производные иногда добавляют атрибуты, которые компилятор знает, чтобы игнорировать. Этот контекст теряется, когда он проходит через настраиваемое наследование. Я бы ожидал, что функция идентификации, заданная как настраиваемая производная, не будет работать, но это вызовет ошибки, связанные с добавлением атрибута #[structural_match] .

Репродукция сценария

(В ящике с названием demo_plugin )

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

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

(в другом ящике)

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

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

Удаление #[derive(Eq)] заставляет все работать нормально.

@sgrif ах да, действительно, спасибо, что напомнили мне!

Итак, здесь происходит несколько вещей:

• С #[derive(PartialEq, Eq)] компилятор молча добавляет #[structural_match] потому что он статически понимает, что вывод PartialEq действительно выполняет этот контракт.
• Я считаю, что аналогичный атрибут возникает при добавлении #[derive(Copy, Clone)] с добавлением #[rustc_copy_clone_marker] .
• В настоящее время это работает, потому что диапазон этих атрибутов говорит «допускает внутреннюю нестабильность». Однако мы теряем информацию о диапазоне при синтаксическом анализе и повторном анализе.

Итак, некоторые решения, которые мы могли бы сделать:

• Обычно говорят, что на первом месте идет кастомное извлечение, например #[derive(Foo, Eq, PartialEq)]
• Положитесь на настраиваемую производную, чтобы опустить эти атрибуты
• Не генерировать настраиваемые атрибуты, если мы обнаруживаем настраиваемую производную
• Используйте совершенно другой механизм в компиляторе для передачи того, что говорят эти атрибуты, но не через сам AST.

Я был бы за то, чтобы либо не использовать эти атрибуты, либо использовать другой механизм. Однако это действительно сложно, потому что #[derive(Copy, Foo, Clone)] также должен работать (где в середине выполняется специальный код, который может изменить определения).

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

Отказ от ответственности: у меня есть только внешний вид компилятора, поэтому я многого не знаю. ^^

Но, насколько я понимаю, текущий подход к созданию настраиваемых макросов 1.1 больше похож на временный обходной путь. Временное решение может означать «довольно долго». Но в конечном итоге (= макросы 2.0) мы больше не будем выполнять циклический анализ строк, что в настоящее время приводит к потере информации диапазона. Интересно, были ли эти скрытые атрибуты в AST такой плохой вещью в мире макросов 2.0? Может быть, кто-нибудь, кто знает компилятор изнутри, сможет сказать. Если эти скрытые атрибуты действительно имеют смысл в этом будущем мире, я бы поспорил с обходным путем, традиционно помещая пользовательские производные. В любом случае, это уже обходной путь, не так ли?

@ colin-kiegel Я считаю, что вы правы в том смысле, что то, что мы делаем сейчас, _не_ будущее. Допустим, у вас есть, например:

#[derive(Eq, Foo, PartialEq)]

Сегодня мы добавим реализацию Eq , затем запустим специальный код для Foo , а затем добавим реализацию PartialEq . Структура может _заменяться_ между Eq и PartialEq , поэтому #[structural_match] добавленное Eq может быть некорректным после выполнения Foo .

В этом смысле я согласен с тем, что в любом случае они не обязательно рассчитаны на будущее!

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

Да, я верю, что такая возможность всегда будет (присуща интерфейсу TokenStream -> TokenStream), хотя я подозреваю, что любая разумная реализация #[derive] сохранит структуру исходной структуры.

Я не думаю, что мы могли бы потребовать, чтобы выходной поток токенов не содержал саму структуру, чтобы гарантировать, что структура не изменится? Входная структура TokenStream будет неизменным префиксом? Большая проблема будет заключаться в игнорировании нераспознанных атрибутов, которые плагины используют после завершения сборки. Возможно, каждый # [derive ()] может иметь префикс (скажем, # [derive (Foo)] имеет префикс Foo_), с которого должны начинаться атрибуты, которые они понимают, и после обработки каждого настраиваемого наследования мы удаляем эти атрибуты?

@mystor, да, проблема с этим подходом - нераспознанные атрибуты, поэтому на входе у нас есть вся структура. Обычно это более гибко, чем полагаться на конкретный префикс / суффикс / регистрацию / и т. Д.

Если настраиваемая производная версия v2.0 может помечать настраиваемые атрибуты как _используемые_, она может быть ограничена доступом только для чтения к остальной части потока токенов элементов. Таким образом, IMO может гарантировать лучшую компонуемость пользовательских производных. Если макросу v2.0 необходимо изменить структуру элемента, ему придется использовать другой API, но не настраиваемое производное. Таким образом, проблема с #[structural_mach] и упорядочением (настраиваемых) производных будет присутствовать только в макросах 1.1. Это имело бы смысл?

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

Скрипт воспроизведения

В ящике под названием demo_plugin

#![feature(rustc_macro, rustc_macro_lib)]

extern crate rustc_macro;

use rustc_macro::TokenStream;

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

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

В другом ящике

#![feature(rustc_macro)]

#[macro_use] extern crate demo_plugin;

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

Ошибка будет выделять Foo даже если Bar запаниковал.

Спасибо за отчет @sgrif! Я обновил описание этой проблемы и надеюсь также отслеживать все нерешенные проблемы, связанные с макросами 1.1.

Хм, взаимодействие custom derive с #[structural_eq] - это то, о чем я раньше не думал. Меня это скорее беспокоит!

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

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

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

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

@nrc ну, это все еще может быть tokenstream -> tokenstream, где мы просто не предоставляем метод new который начинается с нуля, верно?

Я согласен с тем, что должна иметься возможность иметь настраиваемые атрибуты в полях, чтобы настраиваемый производный объект действительно имел смысл. Но я считаю, что может быть много способов сделать это в стиле «добавить» - это, конечно, следует обсудить. Я определенно предпочитаю стиль добавления, потому что я предпочитаю мир, в котором макросы наследования не изменяют элемент и являются компонуемыми, плюс это решает проблему #[structural_eq] . ИМО, это как раз то количество свободы.

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

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

В моих различных библиотеках в настоящее время есть макросы вида foo!(Bar, parameters...) , которые генерируют структуру Bar из параметров.

Во время некоторого обсуждения IRC у нас возникла идея написать вместо этого #[derive(Foo)] #[params] struct Bar; и заменить foo! на #[derive(Foo)] которое будет генерировать тело структуры.

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

Интересно, можем ли мы переделать #[structural_match] чтобы вместо этого помещать его в сгенерированный impl.

(На самом деле не решает проблему)

Стоит отметить, что как Serde, так и Diesel широко используют настраиваемые атрибуты в полях, поэтому существует определенная необходимость в настраиваемом наследовании для возможности замены.

Так что на самом деле, возможно, я просто не думаю о проблеме #[structural_match] . В конце концов, что может сделать кастомная производная?

• Если настраиваемая производная команда ложно вставляет атрибут #[structural_match] , она не пройдёт проверку стабильности. Если нет, то это похоже на ошибку! (Однако, учитывая сложный и дурацкий способ работы этого кода, меня это не удивит.)
• Если пользовательский производный удалит его, никакого вреда не будет.

Извините за то, что написал массу мелких комментариев и подумал вслух, но есть еще одно беспокойство. Хотя настраиваемая производная версия может быть не в состоянии «подделать» аннотацию #[structural_match] (потому что она завершится без «волшебного диапазона»), это, вероятно, приведет к искажению диапазона любой существующей аннотации, если только производные применяются в правильном порядке, что прискорбно. По сути, это пример несовместимости, о которой говорил @ colin-kiegel, но без какой-либо попытки изменить структуру в полете.

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

РЕДАКТИРОВАТЬ: ОК, читая назад, я вижу, что я только что переопределил то, что уже сообщил

Это также довольно грубо, потому что это означает, что мы раскрываем детали нестабильной реализации стабильному коду. Идеально стабильный код никогда бы даже не узнал о существовании аннотации #[structural_match] .

@nikomatsakis Ну, так или иначе, нам нужно наложить различные ограничения в зависимости от того, предназначен ли макрос для пользовательского производного или какого-либо другого типа. Это означает некоторую отдельную обработку (и другую семантику) независимо от сигнатуры функции.

@ colin-kiegel

Я определенно предпочитаю стиль добавления, потому что я предпочитаю мир, в котором макросы наследования не изменяют элемент и являются компонуемыми, плюс это решает проблему # [structure_eq]. ИМО, это как раз то количество свободы.

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

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

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

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

Я согласен с @jimmycuadra в том, что поддержка настраиваемых атрибутов тем или иным образом является жестким требованием. @nikomatsakis также прав в том, что текущая обработка #[derive(PartialEq, Eq)] не соответствует требованиям, и мы не должны его стабилизировать. Наконец, у @mystor есть очень хороший момент, что пользовательские режимы получения не должны даже знать об этом магическом атрибуте. Мы обязательно захотим добавить что-то еще в будущем, и я не хочу, чтобы макросы 1.1 помешали нам сделать это.

Также Вторя @nrc «s настроения о долгосрочном проектировании пользовательских DERIVE, я думаю, много это сводится к тому, как #[derive] на самом деле работает. Если и когда мы поддерживаем произвольные атрибуты, я думаю, что @nrc имеет хороший смысл только в том, чтобы иметь модификаторы и не иметь декораторов, но #[derive] является довольно особенным, когда настраиваемая производная не определяет новый атрибут, а скорее просто прикрепляется к существующий.

Прямо сейчас в реализации есть строгое расширение слева направо режимов #[derive] . Все внутренние режимы извлечения разворачиваются в цикле, и всякий раз, когда срабатывает пользовательский режим извлечения, мы повторно сериализуем, расширяем, а затем возвращаемся к этапу 1. Это, в свою очередь, означает, что компилятор может запускать атрибут #[derive] _ несколько раз для одного. определение типа_. Это приводит к появлению волосатости.

У меня может быть одно предложение - настроить порядок раскрытия #[derive] :

• Во-первых, все настраиваемые производные атрибуты из макроса 1.1 расширяются один за другим. То есть, если у вас есть #[derive(Clone, Foo)] мы сначала извлечем Foo где у структуры есть аннотация #[derive(Clone)] . Если бы этот #[derive] сохранился, мы бы получили встроенную особенность Clone .
• Во-вторых, все производные атрибуты, неизвестные компилятору, расширяются до атрибутов #[derive_Bar] . Это всего лишь уловка обратной совместимости, которую мы должны в какой-то момент удалить, и именно так атрибуты, используемые для расширения.
• Наконец, компилятор расширяет все известные и встроенные атрибуты #[derive]

Это дает удивительный эффект: вы не расширяете слева направо, но опять же помните, что это всего лишь #[derive] . Это дает компилятору максимальные знания об определении структуры, и когда он расширяет встроенные черты, мы знаем, что структура типа никогда не изменится.

Как это звучит? Я считаю, что это решает все ограничения здесь?

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

Был ли когда-либо официально объявлен порядок, в котором обрабатываются производные, как слева направо, через ссылку на Rust или что-то еще? В целом, имеет ли значение порядок атрибутов? Похоже, что это просто случайность, что это было реализовано таким образом, и авторы макросов не должны были полагаться на порядок слева направо. Предложение Алекса по обработке пользовательских запросов происходит в первую очередь, чтобы они никогда не видели магических атрибутов, добавленных компилятором, имеет большой смысл.

Я просто хотел бы добавить, что мне не нравится идея, что пользовательские производные могут изменять макет структуры. Я бы хотел иметь возможность использовать это для чего-то, что важно для безопасности. В качестве примера рассмотрим реализацию #[derive(Trace)] используемую rust-gc .

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

Расширяется до:

struct Foo {
    a: Gc<i32>,
}

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

Однако, если мы разрешим изменять поля в структуре, мы можем определить настраиваемую производную Evil :

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

Расширяется до:

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

Что, если их объединить:

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

Расширяется до:

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

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

Это ненадежная реализация Trace . При использовании с rust-gc это позволяет b быть висящей ссылкой, что ужасно небезопасно и ненадежно. Это означает, что Trace больше не является безопасным для типа #[derive] , что очень прискорбно.

Я лично считаю, что любой хорошо управляемый #[derive] не изменит макет / структуру структуры, а если это произойдет, то вам просто не повезло. Возможность для настраиваемого производного объекта сбрасывать атрибуты имеет решающее значение, и отказ от этого не является основанием для начала. Кроме того, другие реализации, которые включают в себя какие-то формы белых списков или чего-то еще, довольно сильно отличаются от простого интерфейса, который мы имеем сегодня.

Другими словами, я не считаю, что «чистота» того, что #[derive] никогда не изменяет структуру, стоит затрат.

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

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

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

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

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

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

@mystor Это звучит уместно в теории, но помните, что на самом деле вам нужно предоставить все поля структуры в Rust, поэтому гораздо менее вероятно, что он будет работать так тихо, чем, например, в C ++.

@alexcrichton

У меня может быть одно предложение - настроить порядок раскрытия #[derive]

Мне нравится эта идея. Возможно, с точки зрения документации нужно просто заявить, что порядок раскрытия «не определен». В последнее время нам доводилось расширять PartialEq / Eq, но для этого нет строгих причин.

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

PS. Я бы серьезно рассмотрел возможность использования (детерминированного) ГСЧ, засеянного хешем ящика, или чего-то подобного, чтобы изменить порядок расширения пользовательских производных, чтобы люди не могли полагаться на порядок расширения. Я всегда хотел сделать это в каком-то контексте, чтобы предотвратить неявные зависимости, но у меня никогда не было возможности. ;)

РЕДАКТИРОВАТЬ: я передумал и больше не вижу причин запрещать изменение структуры, но вот мой исходный комментарий для контекста

Итак, насколько я понимаю, это аргументы, позволяющие пользовательскому #[derive] изменять структуру:

• Это может быть полезно в некоторых случаях (не видел примеров, но считаю, что они есть)
• Мы хотим иметь возможность удалять атрибуты после того, как они были использованы
• Предоставление дополнительных возможностей авторам настраиваемых производных

Хотя аргументы для добавления ограничений к пользовательским реализациям #[derive] (например, требование, чтобы имя структуры и поля / имена полей в структуре оставались такими же):

• Это позволяет коду, сгенерированному пользовательским #[derive] зависеть от структуры типа, от которого он был получен для надежности (например, #[derive(Trace)] из rust-gc, который _должен_ видеть фактический тип подложки, или это ненадежно, возможно, тонким образом используется после бесплатного использования)
• Это снижает вероятность неявных зависимостей в расширениях макросов, поскольку меньше информации передается между ними через структуру

На мой взгляд, чрезвычайно важна возможность написания звуковых реализаций пользовательского вывода, которые генерируют unsafe trait impls или код, который зависит от небезопасного кода, и я считаю, что есть способы реализовать большинство возможностей в первом разделе ( за исключением возможности добавлять поля структуры) безопасным способом. Если у нас нет каких-либо ограничений, я не думаю, что ящики, такие как rust-gc, можно будет безопасно реализовать. У меня есть две идеи:

Идея 1

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

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

Идея 2

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

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

TL; DR

Подводя итог, я хотел бы понять, в чем особенное преимущество разрешения мутирующих структур и почему это перевешивает проблемы безопасности, связанные с безопасностью #[derive(Trace)] и возможностью всегда правильного #[derive(Serialize)] и т. Д. Я уверен, что если мы в конечном итоге пойдем по маршруту мутирующих структур, для этого будет веская причина, но мне будет очень грустно изменить имя моего пользовательского наследования Trace на #[derive(unsafe_Trace)] .

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

Несмотря на то, что @mystor имеет хорошую точку зрения, это может привести к неприятным сюрпризам, но возможность изменить struct кажется обязательной. С другой стороны, ящики, сочетающие в себе варианты использования процедурных макросов, небезопасный код и проблемы безопасности, кажутся довольно редкими.

Не по теме: эта реализация предоставит макросу возможность корректно сообщать об ошибках?

Мне нравится идея @nikomatsakis рандомизировать порядок расширения пользовательских производных. Это определенно поможет предотвратить чрезмерную популярность «плохих» обычаев - и не стоит прилагать слишком много усилий.

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

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

@sgrif, вероятно, верен в _ большинстве_ случаев, но не так сильно, если вы также получаете и используете черту по умолчанию или что-то подобное.

@sgrif PS: Это правда, что большинство авторов ржавчины, вероятно, понимают, что происходит в их собственном коде, и поэтому могут не удивиться структурным изменениям, если они решили использовать такой макрос намеренно.

Общий вариант применения макросов к структурам - это, безусловно, комбинация структурных изменений + декораций. Но я ожидаю, что общее соотношение будет «много украшений» с «всего лишь несколькими изменениями». Здесь хорошо иметь четкое разделение, потому что это улучшает читаемость и гибкость.

• гибкость: скажем, вы хотите применить два пользовательских производных, которые оба выполняют и то и другое, т. е. изменяют и украшают. Независимо от того, как вы их заказываете, вы можете не получить желаемый результат. Однако, если изменение происходит с помощью другого механизма и все декорации применяются впоследствии, у вас есть возможность комбинировать несколько изменений и украшений более управляемым способом.
• читаемость: если вы читаете чей-то код elses, и к структуре применено 10 производных, и один из них изменяет структуру, вам потребуется больше времени, чтобы понять это.

Итак, хотя я считаю эту часть аргумента @mystor убедительной:

Это позволяет коду, сгенерированному настраиваемым # [derive], зависеть от структуры типа, от которого он является производным для надежности (например, # [derive (Trace)] из rust-gc, который должен видеть фактический тип поддержки, или это ненадежно, возможно, тонкое использование после бесплатного использования)

Я думаю, что попытка навязать это в производном может быть неправильным путем. В частности, нам, вероятно, действительно нужна возможность изменять определения структур в общем случае (да, это не будет прозрачным, но что с того). Это означает, что идея иметь "здоровую" Trace которая может быть уверена, что структура не изменится впоследствии, может быть решена каким-то _ другим_ способом. Подумайте, применяются ли декораторы снизу вверх:

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

Можно подумать, что Trace impl можно записать таким образом, что _it_ не сможет скомпилировать, если определение struct изменится. Например:

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

Обратите внимание, что #[mangle] также может испортить ваш impl, если он действительно дьявольский. =) Здесь мы можем сделать так много.

Как наблюдатель за этими разговорами, я был бы счастлив иметь формальное или неформальное правило, согласно которому #[derive] разрешено только добавлять блоки impl и вводить аннотацию для родственников ( #[mangle(Foo, Bar)] звуки хорошо для меня 😸), посвященный изменению структуры типа. #[mangle] может иметь определенный порядок оценки.

Вероятно, между аннотациями должен быть определенный порядок оценки, если он еще не установлен.

Я думаю, что мои мнения по этому поводу смягчились. @nikomatsakis хорошо let Foo{ ... } похоже, сработает для проверки правильности макета в нормальных случаях. Однако нам, вероятно, нужно будет где-то задокументировать это, чтобы всем не приходилось открывать это самостоятельно.

@nikomatsakis

• mh ... может быть дополнительное правило, что _custom декораторы должны применяться перед derive_, плюс _derives не может изменять элемент_. Это все равно позволит укрепить / очистить механику извлечения в целом.

Но я также рад видеть, что есть еще один способ укрепить индивидуальные производные от более поздних изменений. :-)

Что касается случаев, когда необходимо изменить внутреннюю часть элемента, к которому применяется атрибут, я только что наткнулся на ветку «Предварительная обратная связь для Qt с Rust» в u.r-l.o и написал следующее сообщение:

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

Один примечательный аспект заключается в том, что здесь я предлагаю применить #[derive] (или аналогичный) к _trait_, а не к структуре - и добавленный внутри него элемент будет методом const trait. .

Как и в случае с проблемами груза, которые я поднял выше, я не уверен в

#[macro_use]
extern crate double;

импорт процедурных макросов из ящика с именем double . Поскольку мы используем код времени выполнения (как в реальном Ruest) во время компиляции, должен быть оператор импорта с фазовым приращением, аналогичный Racket (require (for-syntax ...)) . [Документ Racket: https://docs.racket-lang.org/reference/require.html#% 28form ._% 28% 28lib._racket% 2Fprivate% 2Fbase..rkt% 29._for-meta% 29% 29, к сожалению, я не могу понять, как связать нужный раздел.]

Сообщение в блоге http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/ указывает на ошибки фазирования, сделанные в Template Haskell, и может представлять интерес: - Я не хочу повторять те же ошибки в Rust.

@ Ericson2314 Разница в Rust в том, что double уже скомпилирован _ для определенной фазы_.
То есть ящик экспортирует только интерфейс макроса / модификатора, как если бы они были определены, например, macro_rules .
Было бы интересно иметь возможность создавать ящики, которые экспортируют как процедурные макросы, так и базовые элементы Rust (которые образуют процедурный макрос), но пока, похоже, это не предлагается в каком-либо качестве.

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

Да, @eddyb. Я скептически отношусь к методологии «create знает, как это будет использоваться ниже по течению». Если что-то из этапов для нас важнее, чем Racket, из-за нашей модели компиляции (я даже не уверен, может ли Racket кросс-компиляция), поэтому я не понимаю вашего последнего аргумента.

Выдвинута для обсуждения в языковой группе плана стабилизации.

Что касается serde, вот краткий список нерешенных проблем, прежде чем мы сможем прекратить поддержку существующего плагина компилятора и официально рекомендовать Macros 1.1 для всех ночных пользователей: https://github.com/serde-rs/serde/issues/545. Единственное, что нам нужно от Rust, - это исправить # 36211. Во всем остальном мы быстро прогрессируем.

У меня есть открытый PR, который реализует наш rustc_macro без использования syntex, поэтому мы можем перестать беспокоиться о времени компиляции https://github.com/serde-rs/serde/pull/548.

РЕДАКТИРОВАТЬ: неважно, # 36211 повлиял только на старую реализацию syntex

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

@dtolnay, учитывая

@sgrif круто , спасибо! Как только вы это сделаете (или раньше), не могли бы вы прокомментировать здесь любые оставшиеся блокировщики, с которыми вы столкнулись?

Да, я согласен.

Во вторник, 27 сентября 2016 г., 19:29 Alex Crichton [email protected]
написал:

@dtolnay https://github.com/dtolnay с учетом serde-rs / serde # 548
https://github.com/serde-rs/serde/pull/548 , остались ли
блокираторы для серде?

@sgrif https://github.com/sgrif круто , спасибо! Как только вы это сделаете
(или раньше) не могли бы вы прокомментировать здесь оставшиеся блокировщики, которые вы
столкнулись?

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

@alexcrichton

Учитывая serde-rs / serde # 548, есть ли еще блокаторы для serde?

Нет, если @ oli-obk или @erickt проверит этот PR сегодня или завтра, то я могу выложить все на следующий день и перенести нескольких известных пользователей, таких как Rusoto.

@dtolnay Делаю интенсивное использование serde_macros в Руме и хотел бы помочь вам тест serde_derive , а также, если вам нужно больше глаз.

Фактически, я тоже использую diesel_codegen, так что Ruma - хорошая площадка для тестирования версии Macros 1.1 обеих этих библиотек.

Я выпустил Serde 0.8.10, объявив, что serde_macros устарел в пользу Macros 1.1.

Добавим галочку для "Cargo doc works" - https://github.com/rust-lang/cargo/issues/3132.

@dtolnay готово!

Не уверен, что это ошибки serde_derive или ошибки rustc / rustdoc, но я замечаю две проблемы в сгенерированных документах:

• Литерал «///» появляется в начале сгенерированных строк документации для типов, использующих настраиваемое наследование.
• Deserialize и Serialize не отображаются в разделе «Реализации признаков» для типов, использующих настраиваемое наследование.

Литерал «///» появляется в начале сгенерированных строк документации для типов, использующих настраиваемое наследование.

Это была ошибка syn . Я выпустил 0.8.2 с исправлением, поэтому cargo update чтобы его забрать.

Насчет второго я не знаю, оставлю это @alexcrichton.

@jimmycuadra

• Deserialize и Serialize не отображаются в разделе «Реализации признаков» для типов, использующих настраиваемое наследование.

Звучит довольно подозрительно! Похоже, это ошибка в rustdoc, но, возможно, не новая. Например, rustdoc не показывает этого с реализацией Copy :

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

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

Этот шаблон используется serde-derive для генерации импы. @dtolnay была ли у serde_macros такая же форма генерации? Можно ли сейчас отказаться от решения проблемы с документацией?

@jimmycuadra хотите открыть отдельную ошибку, чтобы отслеживать проблему с rustdoc?

@dtolnay была ли у serde_macros такая же форма генерации?

Да.

Можно ли сейчас отказаться от решения проблемы с документацией?

Нет. Насколько мне известно, это единственное решение, которое удовлетворяет обоим этим ограничениям:

• Должен поддерживать serde не в корне ящика, т.е. не ::serde . Это обычное дело, когда люди помещают serde impls за флагом функции в отдельном модуле.
• Должна уметь использовать частные типы из окружающего модуля.

Подробности смотрите на https://github.com/serde-rs/serde/issues/159 .

@dtolnay ах, хорошо, чтобы уточнить, @jimmycuadra это не регресс, верно?

Обновление: не совсем готово с портом, но почти готово. Никаких проблем, кроме вещей, о которых я уже сообщал, или незначительных ограничений, с которыми, как мы знали, мы столкнемся. Наверное, безопасно поставить галочку в поле «Дизель работает», завтра у нас будет выпуск Macros 1.1, если этого не произойдет сегодня вечером.

Для тех, кто следит за мной, я открыл # 36945 и переименовал rustc_macro в proc_macro практически везде, что, по-видимому, является консенсусом по названию этого ящика.

Похоже, что отсутствующие реализации трейтов в rustdoc (которые сейчас отслеживаются в другом выпуске) не относятся к Macros 1.1. Можно игнорировать.

Я попытался перенести свою библиотеку mockers из подключаемого модуля компилятора в макросы 1.1 и получил «ошибку: настраиваемые атрибуты наследования могут применяться только к элементам struct / enum». С помощью подключаемого модуля компилятора возможно (хотя и несколько странно) использовать "derive" для свойств. Мне тут не повезло?

@kriomant интересно! Я думаю, что на самом деле это может быть ошибка в пользовательском наследовании сегодня, поскольку я не уверен, что это когда-либо было предназначено для того, чтобы #[derive] применить к трейту ...

Я думаю, что пока мы будем консервативными, мы, скорее всего, пока не будем _stabilize_ derive-on-traits, но, возможно, мы могли бы добавить для этого нестабильную функцию. Мысли @ rust-lang / lang?

@alexcrichton В чем разница между

@KalitaAlexey нет, это искусственное ограничение для соответствия реальной реализации derive

@alexcrichton Можем ли мы оказать поддержку чертам характера?

Как я уже упоминал выше , вероятно, ошибка, заключающаяся в том, что настраиваемое наследование когда-либо разрешалось для свойств, а это не было указано в RFC, поэтому перед расширением необходимо провести дополнительное обсуждение. В любом случае, поддержка derive-on-trait вряд ли будет стабилизирована на первом проходе, но мы могли бы рассмотреть отдельные ворота для функций.

Я лично не хотел бы добавлять наследование по признаку, так как это больше похоже на территорию настраиваемых атрибутов, чем само по себе. (например, идет вразрез с духом #[derive] в исходном виде)

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

@alexcrichton

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

👍 от меня.

Хорошо, нестабильная функция - это хорошо, но это означает, что моя библиотека не будет работать стабильно (без генерации кода). И синтаксис macro!(…) тоже не распространяется на "макросы 1.1", я прав?

Я пересматриваю RFC макроса proc, и был план, что ящики макросов должны объявлять себя #[cfg(macro)] . Для макросов 1.1 это не требуется, но нам нужен специальный тип ящика. Эти два механизма в некоторой степени ортогональны - первый описывает фазу компиляции, второй - вид корзины. Но они также в некоторой степени пересекаются - последнее подразумевает первое. Первый также масштабируется для объявления макросов proc и немакро-функций в одних и тех же ящиках, а второй - нет.

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

@kriomant правильно, да

@nrc прямо сейчас определяется как cfg(rustc_macro) (хотя скоро изменится на proc_macro ). Нам это не нужно, нет, но я думал, что это будет необходимо для концепции как связывания с ящиком во время компиляции, так и во время выполнения? То есть мы бы скомпилировали ящик proc-macro дважды: один раз с типом ящика proc-macro и один раз с типом ящика rlib , и последний не будет ссылаться на libsyntax или что-то подобное. тот.

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

@alexcrichton Может ли #[proc_macro_derive] подразумевать это? Точно так же #[test] подразумевает #[cfg(test)] .
(Это не означает, что мы должны добавить его сейчас, просто худший случай, если мы добавим cfg - это предупреждения о неиспользуемых элементах.)

@eddyb А как насчет extern crate proc_macro; ? Я чувствую, что они тоже сломаются.

@mystor Это просто обычный ящик с кучей типов и импов.

Разве он также не связан с libsyntax , что означает, что, если бы ящик использовал ящик proc_macro и хотел бы выполнить кросс-компиляцию, ему также придется использовать синтаксис кросс-компиляции?

@eddyb yes #[proc_macro_derive] может автоматически игнорироваться, но проблема в том, что мы _также_ должны игнорировать все, что эти функции транзитивно достигают (например, extern crate proc_macro ). Хотя это «просто ящик», он имеет серьезные последствия во время выполнения (динамическое связывание, недоступное для кросс-скомпилированных целей и т. Д.).

Обратите внимание, что в тестах есть #[cfg(test)] , поэтому мне кажется разумным, что мы по-прежнему используем #[cfg(proc_macro)] для той же цели.

@alexcrichton _Идеально_, в ящике не должно быть ничего, кроме того, что экспортируется, и не требуется динамического связывания или чего-то подобного, только libstd . Однако я мог видеть, что это вызывает проблемы в случаях #![no_std] .

Похоже, нам придется с самого начала выполнить двойную компиляцию, если мы хотим все уловить: dis provided :.

РЕДАКТИРОВАТЬ : Подождите, о чем я вообще думаю? Для этого требуется специальный тип ящика, двойная компиляция применяется к _регулярным_ ящикам, которые _также_ экспортируют процедурные макросы / атрибуты / производные / и т. Д. Так что сейчас это не актуально.
Но мы могли бы хотя бы ввести #[cfg(proc_macro)] который всегда устанавливается для нового типа ящика.

🔔 Эта функция вступает в последний период обсуждения с намерением стабилизироваться в конце этого цикла выпуска! 🔔

Основанием для рассмотрения вопроса о стабилизации сейчас является:

• Поверхность API этой функции по своему замыслу _ чрезвычайно_ консервативна. В то же время он совместим с де-факто планом процедурных макросов.
• Эта функция быстро получает широкое распространение через Serde, а вскоре и через Diesel, хотя, что примечательно, широкое распространение в основном используется в качестве _клиента_ настраиваемого происхождения.
• Переход на FCP теперь дает нам три месяца до того, как функция будет фактически отправлена ​​в стабильную версию, что должно быть достаточно времени, чтобы устранить любые оставшиеся проблемы.

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

Двойная сборка ящика звучит очень грубо: определение объема не будет работать правильно. На самом деле что-то вроде extern! crate needed_for_my_inline_proc_macros; - гораздо лучшее решение.

@aturon что, разве люди не начали использовать это несколько дней назад?

@ Ericson2314 Прошло немного больше времени, но, как объясняется в комментарии FCP, _минимальное_ время до отправки на стабильный канал составляет три месяца, что, по нашему мнению, более чем достаточно для этого чрезвычайно узкого интерфейса.

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

Ах хорошо. Я вспомнил о трехмесячной части, но забыл, где находится FCP в этих трех устьях - чтобы не было трех месяцев с 22 августа. Тогда не обращайте внимания на время.

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

@alexcrichton rustc_copy_clone_marker и другие rustc_attrs все еще кусают нас. См. Https://github.com/serde-rs/serde/issues/577.

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

Обходной путь - поменять местами порядок, но я решил проверить, можно ли это исправить.

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

Я закончил перенос https://github.com/sfackler/rust-postgres-derive на макросы 1.1. Это было относительно безболезненно, но обработка атрибутов, считываемых несколькими производными, - огромная боль. Серде столкнулся с тем же самым, но для одновременного расширения обоих производных требуется несколько странных логических решений: https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-internals/ src / lib.rs # L26

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

Я выпустил quote 0.3.0 с поддержкой причудливых повторений в стиле macro_rules! (спасибо @nrc за подталкивание). Если вы разрабатываете макросы proc без quasi / syntex, вы, вероятно, захотите этого. Пример использования из postgres-derive:

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

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

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

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

Мне любопытно, почему # а не $ ?

РЕДАКТИРОВАТЬ : Всегда думал, что синтаксис цитирования будет ${...} но, возможно, я слишком привязан к шаблонным литералам ES6, даже если это было несколько лет. \{...} тоже работает, хотя может пригодиться в другом месте.
Кажется, что нет скобок, но мне не о чем беспокоиться.

Мне любопытно, почему # а не $ ?

Потому что это макрос macro_rules, и я не могу делать то, что хочу: smile :. $v сопоставляется как отдельный токен, и нет возможности перейти от $v к использованию переменной v . Напротив, #v - это два токена, поэтому я могу сопоставить их по отдельности и сделать что-то с идентификатором.

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

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

Подождите, все это делается в macro_rules ?! Забыл макросы 1.1 был производным только на мгновение. Тем не менее, $x являющийся одним токеном, является недостатком дизайна ИМО. cc @jseyfried

@dtolnay

@alexcrichton, rustc_copy_clone_marker и другие rustc_attrs все еще кусают нас. См. Serde-rs / serde # 577.

Ой, кажется, это плохо! Обновлю список вверху. @nrc или @jseyfried мысли о том, как с этим справиться? Я не слишком знаком с порядком раскрытия всего, но, может быть, когда один атрибут #[derive] расширяется, он может попытаться проглотить все будущие и сделать это первым?

@sfackler

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

Я не уверен, что следовал примеру, на который вы ссылались, не могли бы вы уточнить?

@alexcrichton Возьмем для примера

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

Атрибут #[postgres] используется для настройки того, как генерируются реализации ToSql и FromSql . Он должен быть удален перед окончательным выводом, поскольку в противном случае это неизвестный атрибут, но реализации ToSql и FromSql выполняются отдельно. Если вы сделаете это наивным способом, просто сгенерировав реализацию, а затем удалив атрибуты, во втором производном будет не хватать настроек.

Serde-derive и postgres-derive пытаются решить эту проблему прямо сейчас, имея реализацию для обоих производных импов, перенаправляя их на одну и ту же функцию, которая генерирует оба сразу. Мы должны повторно прикрепить #[derive] для того, который в настоящее время вызывается, поскольку компилятор удаляет его, а затем отправить его для расширения: https://github.com/sfackler/rust-postgres-derive/blob /master/postgres-derive/src/lib.rs#L18

@sfackler Я _ думаю_, что вы также можете сделать это, удалив лишние атрибуты только тогда, когда не осталось производных от того же разработчика. Ваш способ может быть лучше _shrug_.

@sfackler ах, хорошо, имеет смысл. Благодаря!

Интересно, может ли эта логика быть хрупкой. Например, если вы расширяете ToSql как обнаруживается будущее расширение FromSql ? Это могло быть за #[cfg] вроде @dtolnay, упомянутого выше ? Значит, это не во всех случаях возможно обнаружить?

@alexcrichton Да, он хрупкий, поэтому реальное решение кажется важным.

Разве #[cfg] и #[cfg_attr] будут обработаны перед производством?

Поскольку api макросов 1.1 работает со строками, я могу представить только три решения:

1. оставьте как есть и дождитесь макросов 2.0
2. разрешить неиспользуемые атрибуты в настраиваемой производной
3. расширить api макросов 1.1, позволив настраиваемому производному помещать имена атрибутов в определенный белый список для текущего элемента

У каждого варианта есть свои плюсы и минусы.
Минус 1: пока что хрупкие обходные пути
Con 2: некоторые неиспользуемые атрибуты не будут обнаружены
con 3: больше поверхности API для промежуточного решения

Я подумал об установке атрибутов в #[used(...)] чтобы сохранить их и добавить в белый список одновременно, но это довольно глупо и слишком быстро стабильно.

@alexcrichton

когда один атрибут #[derive] расширяется, он может попытаться поглотить все будущие

Мне нравится эта идея. Поскольку #[cfg] s и #[cfg_attr] s обрабатываются до #[derive] s, #[cfg] -guarded #[derive] s не является проблемой для этого подхода. (или аналогичное решение @sfackler для

Такой подход позволил бы сделать @sfackler «решение s немного проще, так как другие соответствующим производными может быть только в последнем атрибуте (я также думаю , что @eddyb» s предложение позволило бы упростить вещи).

Одна из возможностей проблемы с атрибутами управления - добавить обратные вызовы после расширения, несколько похожие на синтекс: https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/lib. rs # L23 -L50

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

Дизель также вручную работает над этим. https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L101 -L112

@dtolnay ваша предыдущая озабоченность по поводу нескольких атрибутов #[derive] должна быть исправлена ​​в ближайшее время благодаря @jseyfried

Я поигрался с этим, используя пакеты syn и quote , и получил действительно положительный опыт. Это будет отличная особенность, когда она стабилизируется.

Проблема с атрибутами в настоящее время укусила мой impl, находясь ниже по течению от логики вывода serde s.

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

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

Итак, у меня отсутствовала точка с запятой в пути к типу внутри функции generic, и я получил следующее сообщение об ошибке от rustc. Мне интересно, можно ли предоставить дополнительную информацию, например, какой макрос derive вызвал ошибку lex, какой токен ее вызвал и т. Д.

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

Я сделал тестовый пример для LexError, похоже, это произошло с ночным 13 октября (у rustup не было обновлений) https://github.com/keeperofdakeys/proc_macro_derive_test.

@ rust-lang / lang Я думаю, нам нужно обсудить вопрос о том, могут ли производные объекты изменять свой аннотированный элемент. Хотя это простое решение, похоже, оно противоречит ожиданиям пользователей и кажется довольно непопулярным. Я по-прежнему предпочитаю текущее решение - простота приятна, и ни одна из предложенных альтернатив не кажется мне лучше.

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

Кто-то должен дать определение «модифицировать». Мы говорим об изменении членов структуры или просто об удалении атрибутов, чтобы компилятор не жаловался на неизвестные атрибуты?

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

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

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

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

• Применение поведенческого контракта производного, безусловно, мне больше похоже на решение Rust.
• Заставить serde и deisel работать с этим ограничением представляет множество проблем.

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

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

@sgrif Не могли бы вы рассказать о том, как deisel использует derive? Мне кажется, я понимаю, как serde использует свою способность изменять структуру (для удаления атрибутов, которые информируют макрос об исключении или переименовании полей в признаке сериализации), но, возможно, deisel использует это для чего-то другого. Когда вы говорите «удалить аннотированный элемент», создается впечатление, что вы выполняете довольно радикальное преобразование этого элемента.

@withoutboats 90% - это более или менее то, что вы ожидаете. Мы не трогаем предметы, предоставленные пользователем. Тем не менее, мы удаляем аннотированные элементы, чтобы взломать макросы bang в систему. https://github.com/diesel-rs/diesel/blob/master/diesel/src/macros/macros_from_codegen.rs#L12 -L18. Помимо этого, единственный раз, когда мы касаемся чего-либо во входном потоке токенов, мы удаляем аннотации. https://github.com/diesel-rs/diesel/blob/master/diesel_codegen/src/lib.rs#L109 -L120

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

Однако я могу понять аргумент в пользу сохранения производной функции как простой макрос.

Я считаю, что цель Macros 1.1 - быть как можно более гибкой, чтобы удовлетворить как можно больше потребностей, с минимальными затратами на обслуживание, чтобы его можно было быстро стабилизировать и действовать как временный переход до появления макросов 2.0. На мой взгляд, нынешний дизайн очень хорошо подходит для этой роли.

Если бы мы говорили о чем-то, что предназначено для постоянного выполнения этой роли, я был бы гораздо более против.

Может быть, я ошибаюсь, но мое прочтение RFC говорит о том, что он предназначен для того, чтобы быть основой для поведения производной на постоянной основе. То есть в будущем в TokenStream будут добавлены дополнительные методы, но макросы извлечения будут использовать этот API, который в настоящее время позволяет им выполнять произвольные мутации в аннотированном элементе (и эта возможность необходима для варианта использования deisel ).

Я довольно негативно отношусь к тому, чтобы позволять деривам делать это навсегда. Если мы согласимся с тем, что эта система будет устаревшей вместе с макросами macro_rules в какой-то момент в будущем, а в рамках макросов 2.0 предпочтение будет отдано другому API деривации, который более ограничен, я с ним комфортнее.

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

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

@eddyb Я за то, чтобы декораторы могли делать что угодно, но не за то, чтобы деривы были безудержными декораторами (в долгосрочной перспективе).

@erickt Верно. Я думаю, что в долгосрочной перспективе идеальным решением было бы, чтобы эти атрибуты были зарегистрированы как пользовательские атрибуты без операции, вместо того, чтобы производный объект отвечал за их удаление. Но в краткосрочной перспективе это невозможно.

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

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

Я также заметил, что Diesel не следует подходу Serde, согласно которому все свои настраиваемые атрибуты под одним именем (например, #[serde(rename = "name")] в отличие от #[table_name = "name"] Дизеля). Упростит ли это реализацию, если бы только одно настраиваемое имя атрибута прописался вместо списка?

Одна из возможностей проблемы с атрибутами управления - добавить обратные вызовы после расширения, несколько похожие на синтекс: https://github.com/sfackler/rust-postgres-derive/blob/master/postgres-derive-codegen/src/lib. rs # L23 -L50

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

Я реализовал обратные вызовы после расширения для макросов 1.1 в post-expansion . Ваши производные impls могут быть независимыми и не удалять атрибуты управления, и вы можете зарегистрировать проход, который запускается после того, как все раскрытие выполнено для удаления атрибутов.

Мы обсудили вопрос модификации / заказа сегодня на собрании команды lang. Было желание оправдать ожидания пользователей и для простоты (с точки зрения дизайна, не иметь слишком большого количества хаков на вершинах и не слишком подвержены ошибкам, которые трудно расшифровать / отладить). Было отмечено, что, хотя изменение целевых данных вызывает удивление, оно не небезопасно. Также считалось, что мы могли бы стремиться к чистоте ради самой чистоты, а не по хорошо мотивированным причинам.

В конце концов, мы решили, что производные, которые не изменяют исходный код, вероятно, лучше, и мы должны перейти на эту модель. Это может означать продление периода FCP. Мы не думали, что должен быть специальный механизм для работы с атрибутами удаления. Скорее, то, как компилятор обрабатывает атрибуты, должно позволять тем, которые используются макросом, оставаться в программе. RFC 1755 должен учитывать это.

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

cc @alexcrichton , @dtolnay , @sgrif , @erickt - мысли?

Атрибуты, вероятно, чаще используются с Serde и Diesel, чем вы предлагаете. Исходя из собственного опыта, я уверен, что все мои программы, использующие Serde, используют атрибуты. В Diesel я определенно использую атрибуты, и я думаю, что это необходимо для того, чтобы указать diesel_codegen, какая таблица базы данных сопоставляется со структурой.

Тем не менее, запрет на изменение структуры в custom derive кажется мне правильным выбором. Это просто все упрощает, предотвращая множество странных крайних случаев. Более важно сделать это правильно, чем сделать это быстро, поэтому, если функция должна оставаться нестабильной немного дольше, это тоже кажется прекрасным.

Было отмечено, что, хотя изменение целевых данных вызывает удивление, оно не небезопасно.

Это небезопасно, если только у вас нет небезопасных черт.

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

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

Было бы неплохо разделить настраиваемые атрибуты rfc на две части?

1. RFC для предоставления обозначений и пространств имен для настраиваемых атрибутов в целом (что позволяет использовать атрибуты no-op в стабильной версии).
2. RFC для определения и семантики выполнения макросов настраиваемых атрибутов.

Макросы настраиваемых атрибутов кажутся чем-то, что потребует многого, если их проработать. Таким образом, разделение rfc на два может быстрее обеспечить стабильные атрибуты для настраиваемых производных пакетов.

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

Есть ли причина, по которой эта реализация не включает обычные макросы name! ? Простые TokenStream in, TokenStream out для обычных макросов оказались бы чрезвычайно полезными в борьбе с вредителями, когда время компиляции сложных грамматик превышает 30 секунд.

@dragostis Процитирую резюме

Извлеките в компилятор очень небольшой фрагмент сегодняшней процедурной макросистемы, которого достаточно, чтобы получить базовые функции, такие как работа настраиваемого наследования, и иметь в конечном итоге стабильный API. Убедитесь, что эти функции не будут обременительны для компилятора, но также не пытайтесь одновременно предоставить достаточно функций для «идеальной макросистемы». В целом, это следует рассматривать как постепенный шаг к официальным «макросам 2.0».

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

@keeperofdakeys Ага, понял. Я не прошу реализовать макросы 2.0, мне просто интересно, есть ли какое-либо бремя для добавления другого атрибута, скажем, proc_macro который является минимальной реализацией, которая просто отражает дизайн производной только для обычных макросов. Пример в pest будет просто выводить синтаксический анализатор для struct только он не выводит его из самого struct , а из простой грамматики, определенной между {} . Хотя, надеюсь, я не выкапываю мертвые дискуссии!

@dragostis Я https://internals.rust-lang.org/t/pre-rfc-extend-macros-1-1-to-support-foo-style-macros/3921

@nrc

Также считалось, что мы, возможно, стремимся к чистоте ради самой чистоты, а не по хорошо мотивированным причинам.

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

Что касается стабильности, мы могли бы подумать о добавлении нестабильного механизма для игнорирования атрибутов прямо сейчас, который был бы стабильным на практике (в том смысле, что API не был бы подвержен поломке), даже если он все еще требует ночного использования. Мы могли бы даже подумать о стабилизации такого побочного канала с планами отказаться от него в пользу более общего механизма, когда он будет доступен. Или мы могли бы рассмотреть предложение @keeperofdakeys и быстро решила бы

С моей точки зрения, важно, чтобы ни одна из этих проблем не мешала широко использовать макрос 1.1 для Serde и, по крайней мере, «де-факто» стабильно (т.е. не ломать).

@sgrif

Если бы мы говорили о чем-то, что предназначено для постоянного выполнения этой роли, я был бы гораздо более против.

Я хотел повторить @withoutboats и уточнить, что в настоящее время мы хотим, чтобы поверхность API макросов 1.1 оставалась как есть, даже когда мы отправляем макросы 2.0. Это то, что мы могли бы пересмотреть - мы могли бы думать об этом больше как о сегодняшних macro_rules, с намерением отказаться от рекомендаций, как только окончательная система будет на месте.

Мое впечатление от использования атрибутов на пользовательской DERIVE было похоже на @jimmycuadra «s впечатление , что , что они довольно широко используются. Я считаю (но поправьте меня, если я ошибаюсь), что настраиваемые атрибуты имели решающее значение для ряда вариантов использования дизельного топлива.

В этом смысле я не уверен на 100%, как лучше всего поступить с этими атрибутами. Было бы обидно стабилизировать макросы 1.1, но по-прежнему оставлять большое количество пользователей включенными каждую ночь (даже если он "де-факто стабильный" каждую ночь), потому что это в некоторой степени сводит на нет цель быстрой стабилизации макросов 1.1 в первую очередь. Другими словами, если мы не переводим большинство пользователей макросов 1.1 _ фактически_ на стабильную версию Rust, я думаю, что стабилизация макросов 1.1 может подождать.

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

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

Я склонен переключаться с rustc-serialize на serde, потому что генерация кода serde поддерживает атрибуты управления.

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

Точно так же @sfackler , атрибуты более важны для Serde , чем комментарий @nrc заставляет их звучать. Почти все варианты использования без атрибутов также будут обработаны rustc-serialize. Если мы хотим избавить людей от работы по ночам, мы можем сделать это, отказавшись от Serde в пользу rustc-serialize.

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

#[serde(skip_serializing)]

.. вместо:

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

@tomaka

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

Что вы думаете о моем комментарии по этому поводу? Я обнаружил, что картина удовлетворительная.

Хочу прояснить одну вещь:

Удаление настраиваемых атрибутов - главное, что люди делают с настраиваемым производным?

Я знаю, что есть несколько хаков для расширения foo! в контексте типа (например, @sgrif упомянул такой вариант использования в дизельном топливе, я думаю, @tomaka тоже упомянул один) - насколько

Причина, по которой я спрашиваю, заключается в следующем: я вижу преимущества в том, что механизм извлечения возвращает только список дополнительных элементов. В частности, это означает, что интервалы для самого объявления типа будут правильными. Добавление быстрого и грязного API в контекст, который позволяет вам предоставить список имен атрибутов в белый список в контексте этого типа, кажется достаточно простым исправлением для атрибутов, и мы всегда можем отказаться от него.

Однако, если мы хотим включить больше вариантов использования (и, честно говоря, эти варианты использования немного больше ... удивительны, когда вы думаете о том, чего ожидать от наследования), то это не сработает. В этом случае, я бы , вероятно , будет штраф стабилизирующими как и планирует принизить на «из необработанных байтов» API в будущем в пользу лучшего способа , чтобы написать DERIVE ( в конце концов, мы действительно не ожидаем , что люди будут в любом случае используя необработанные байты, верно? а потоки токенов?) Возможно, мы могли бы дать API более громоздкое имя =)

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

Да, я разрываюсь между двумя подходами, у каждого из которых есть явные недостатки:

1. Подход «простого производного» - настройте API так, чтобы он производил только дополнительные элементы, что делает его по-прежнему нестабильным для пользователей, чтобы использовать настраиваемые атрибуты как часть получения, и закрывая дыру, через которую дизель и другие ящики прыгают, чтобы получить произвольные процедурные макросы.
2. Подход «запланированного устаревания» - стабилизация API как есть, с небольшими корректировками, возможно, такими, как Нико упомянул об именовании, с намерением когда-нибудь отказаться от него. Это потребует от всех создателей настраиваемых производных когда-нибудь переписать свой код и допустить возможность неожиданного поведения в промежуточный период.

EDIT: но белый список

Я имею в виду, что это не похоже на то, что @nrc предлагает что-то

Произвольные процедурные макросы, которые я злоупотреблял системой макросов 1.1 в rust-cpp, были бы полностью возможны с альтернативным подходом, который просто предоставляет возможность добавлять impls и игнорировать атрибуты.

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

Я не уверен, какие формы хаков, которые @sgrif использует в deisel, что было бы невозможно_ сделать в мире, где мы не можем изменять саму структуру, а вместо этого можем только добавлять дополнительные элементы.

Разрешение настраиваемым производным принимать аргументы, как предлагает @sfackler , может быть способом предоставить каждому необходимую функциональность, позволяя при этом отложить принятие любого решения по настраиваемым атрибутам. Он не будет таким красивым или читаемым, но он выполнит свою работу. например:

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

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

И serde, и мой ящик требуют атрибутов field / option. Пытаться подражать этому с помощью аргументов производных не имеет особого смысла, нам нужны атрибуты.

Какое бы решение мы ни приняли, чтобы стабилизировать это, было бы неплохо, если бы пользователю настраиваемых макросов производных не нужно было изменять свой код, когда / если мы переключаемся на макросы 2.0, производные api (очевидно, авторы макросов настраиваемых производных макросов будут). Похоже, что наиболее разумным решением является предоставление компилятору списка атрибутов для удаления для вашего производного объекта, и, что важно, они удаляются только после выполнения _все_ макросов производного объекта. У Serde, Diesel и моего ящика есть проблема с требованием одного и того же атрибута для нескольких производных макросов.

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

FWIW единственная причина для удаления этих атрибутов - сделать HIR более тонким - что касается всего остального, вам нужно только отметить их как использованные.

Удаление настраиваемых атрибутов - главное, что люди делают с настраиваемым производным?

Я знаю, что есть несколько хитростей, чтобы сделать foo! расширение в контексте типа (например, @sgrif упомянул такой вариант использования в дизельном топливе, я думаю, @tomaka тоже упомянул один) - насколько центральными являются эти варианты использования?

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

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

Похоже, в последнем ночном номере произошел регресс. Получение ошибки

Queryable - это режим вывода

при составлении наших примеров.

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

@sgrif Это было вызвано # 37198, который изменил пользовательские производные, чтобы использовать то же пространство имен, что и другие макросы (так что макросы bang!() , #[attribute] макросы #[derive(custom)] все совместно используют то же пространство имен).

В этом примере #[macro_use] extern crate diesel; импортирует макрос bang с именем Queryable а #[macro_use] extern crate diesel_codegen; импортирует настраиваемый макрос получения, также называемый Queryable , который незаметно перезаписывает макрос bang (кроме - #[macro_use] тихая перезапись не идеальна, но не будет проблемой, как только мы сможем импортировать макросы из внешних ящиков с помощью use вместо #[macro_use] , скоро!).

Я считаю, что ошибка вызвана вызовом макроса Bang Queryable!(); в расширении настраиваемого производного объекта, который разрешается в настраиваемый производный объект из diesel_codegen вместо макроса Bang из diesel .

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

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

Реальная проблема в том, что вы не можете использовать use для выборочного импорта или переименования макросов. Таким образом, пользователь ящика не может обойти конфликты имен макросов. В то же время я бы не ожидал, что простой импорт ящика ProcMacro столкнется с именами локальных макросов - я думал, что производные макросы начинаются с derive_ ?

Наличие пространств имен связано со сложностью, и я считаю, что чем их меньше, тем лучше, поэтому вопрос должен заключаться в том, зачем нам нужны разные пространства имен?

Я думаю, что элементы должны разделять пространство имен только в том случае, если они могут быть неоднозначными друг с другом. consts и fns находятся в одном пространстве имен, потому что они оба используются как идентификаторы в контексте выражения. Типы и признаки находятся в одном пространстве имен из-за синтаксиса для объектов признаков.

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

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

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

Если поразмыслить немного подробнее, я бы согласился сказать, что должно быть только одно пространство имен, в котором находятся все элементы - я даже вроде как предпочитаю его; весь шаблон «настоящие конструкторы» немного сбивает с толку ИМО - но это не то решение, которое Rust принял для немакросъемочных элементов, поэтому мне кажется, что было бы более согласованным и ожидаемым, чтобы макро-элементы занимали разные пространства имен.

Настоящая проблема в том, что вы не можете использовать use для выборочного импорта или переименования макросов.

Вы сможете сделать это с помощью макросов 2.0. Модель здесь в основном временная.

Я думал, что макрос derive начинается с derive_?

Это была старая система кастомного вывода, я не думаю, что макрос 1.1 делает это.

Хотя есть стоимость сложности реализации, я не думаю, что есть значительная стоимость в сложности использования.

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

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

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

но это не то решение, которое Rust принял для немакро-элементов

Контрапункт: модули и поля находятся в пространстве имен значений, хотя места, где они могут использоваться, (я думаю) отличаются от мест, где могут использоваться другие значения.

@keeperofdakeys

Реальная проблема в том, что вы не можете использовать use для выборочного импорта или переименования макросов.

Скоро мы сможем использовать макросы use из extern crate s за воротами функций (~ 1 неделя), cf https://github.com/rust-lang/rfcs/pull/1561 и №35896. Мы можем решить стабилизировать макросы use ing из пользовательских ящиков производных вместе с собственными производными.

Я думал, что производные макросы начинаются с derive_

Это было верно для старых обычаев. В макросах 1.1 с настраиваемыми производными макросами #[derive(Serialize)] (например) ожидает, что Serialize разрешится в макрос настраиваемых производных.

@withoutboats

В чем причина использования единого пространства имен для всех трех «видов» макросов?

• Приоритет: макросы bang и макросы атрибутов долгое время совместно использовали пространство имен, поэтому до тех пор, пока это не изменится, я думаю, что пользовательские производные также должны использовать это пространство имен.
• Обратная совместимость: если мы начнем с одного пространства имен макроса, мы можем разделить его обратно совместимо. Если мы начнем с нескольких пространств имен макросов, мы застрянем с ними навсегда.
• Простота: если бы у каждого «вида» макроса было свое собственное пространство имен, у нас было бы пять пространств имен. Таким образом, после того, как https://github.com/rust-lang/rfcs/pull/1561 приземлится, use foo::bar; может импортировать _пять отдельных элементов_ с именем bar (значение, тип, макрос взрыва и т. д.), и не было бы простого способа, например, повторно экспортировать макрос bang, но не макрос пользовательского извлечения, или просто импортировать макрос пользовательского извлечения как baz .

Обратная совместимость: если мы начнем с одного пространства имен макроса, мы можем разделить его обратно совместимо. Если мы начнем с нескольких пространств имен макросов, мы застрянем с ними навсегда.

Это убедительно, особенно с учетом того, что 1.1 должен быть временным средством. : +1:

Этот код прерывания предназначен для тех, у кого был макрос macro_rules с именем, например, PartialEq! ?

Нет, PartialEq сегодня не определен в пространстве имен макросов, так как это не настраиваемая производная.
#[derive(Foo)] сначала проверяет, является ли Foo «встроенной производной» ( PartialEq , Copy и т. Д.), Прежде чем искать настраиваемую производную Foo в пространстве имен макроса. Встроенные команды жестко прописаны в определении derive .

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

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

• За кулисами макросы пользовательского извлечения реализуют трейт, в настоящее время MultiItemModifier . Планируется, что макросы 2.0 будут продолжать реализовывать черту, и эта черта будет использоваться для расширения механизма. Аннотированная функция, которая является макросом, реализует эту черту. Хотя мы не используем регистратор плагинов, это, по сути, удаление сахара.
• мы должны отделить черту CustomDerive специально для макроса 1.1, производного от пользователя. В общем случае авторы макросов никогда этого не видят. Но у них есть возможность реализовать признак напрямую, а не использовать атрибут в функции (я ожидаю, что мы повторно будем использовать атрибут в impl, возможно, нам нужно обсудить этот механизм регистрации).
• мы добавляем функцию declare_attributes к CustomDerive которая возвращает Vec<String> . По умолчанию он возвращает пустой vec.
• Если авторы макроса реализуют этот метод, то любые атрибуты, названные в точности как одна из возвращаемых строк, считаются принадлежащими макросу. Любой такой атрибут никогда не рассматривается как макрос и не запускает настраиваемый атрибут lint. Атрибуты оставлены в коде расширением производных, но помечены как используемые. Любой такой атрибут, который не затрагивается расширением производного объекта, все равно вызовет неиспользуемый атрибут lint (но не настраиваемый атрибут lint).
• В будущем мы могли бы ввести атрибуты с заданной областью, которые могут использовать макросы, включая настраиваемые производные, они будут _ в дополнение_ к declare_attributes и этот механизм не будет устаревшим.
• Альтернатива: строки, возвращаемые declare_attributes , проверяются как префикс пути для атрибутов, например, если declare_attributes вернул vec!["foo::bar"] , то #[foo::bar::baz] и #[foo::bar::qux] будет разрешено.

Мысли? Копия @alexcrichton @jseyfried @dtolnay @sgrif @erickt @ rust-lang / lang

@nrc, позволит ли этот механизм отключить атрибуты _used_, такие как #[cfg(..)] - случайно или намеренно? И можно ли это изменить?

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

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

@nrc Почему это должно быть обязательно и не может быть просто списком в атрибуте, обозначающем функцию расширения производной? Например, #[proc_macro_derive(Serialize, uses_attrs(serde_foo, serde_bar))] или что-то подобное.

@ colin-kiegel Я предполагаю, что это может применяться только в рамках производного приложения, и в этом случае отключение других атрибутов, вероятно, является ожидаемым поведением, хотя я думаю, что мы могли бы применить cfgs до расширения макроса (это изменилось, но я не могу вспомнить до и после).

@alexcrichton

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

Хм, хороший момент, полагаю, нам нужно решить эту проблему для макросов 2.0.

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

Попадание в ловушку - я был за пределами страны, а потом заболел. Я хотел бы вернуться к https://github.com/rust-lang/rust/pull/37198 , так как не думаю, что для всех видов макросов есть смысл занимать одно и то же пространство имен. Я бы по крайней мере ожидал, что макросы пользовательского извлечения будут в этом пространстве имен как derive_Foo или аналогичные. Существуют варианты использования нескольких типов макросов, использующих одно и то же имя даже в стандартной библиотеке (например, #[cfg] и cfg! ).

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

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

@sgrif @ https://github.com/rust-lang/rust/issues/35900#issuecomment -256247659.

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

Чтобы было ясно, макросы Bang и макросы атрибутов всегда занимали одно и то же пространство имен; # 37198 только что перемещенный пользовательский объект наследуется в этом пространстве имен.

Существуют варианты использования нескольких типов макросов, использующих одно и то же имя даже в стандартной библиотеке (например, #[cfg] и cfg! )

В качестве альтернативы cfg можно рассматривать как отдельный макрос, который можно использовать с помощью вызова bang или вызова атрибута (хотя сегодня пользователи не могут определить макрос, который может быть вызван с помощью вызова или атрибута, мы можем решить разрешить это в макросах 2.0).

С точки зрения конечного пользователя может показаться, что существует какая-то взаимозаменяемость.

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

Похоже, что в будущем могут быть введены другие пространства имен, не сильно нарушая

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

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

Похоже, что поломка (https://github.com/diesel-rs/diesel/issues/485) вызвана поддержкой, например, Queryable! { struct S; } а также #[derive(Queryable)] struct S; . Как только пользовательские производные станут стабильными, отпадет необходимость в поддержке Queryable! { struct S; } так что это больше не будет проблемой, верно?

А пока я считаю, что мы могли бы обновить diesel чтобы

• Queryable! по-прежнему поддерживается без #[macro_use] extern crate diesel_codegen; и
• #[derive(Queryable)] , но не Queryable! , поддерживается с помощью #[macro_use] extern crate diesel_codegen; .

Не стесняйтесь пинговать меня в IRC, чтобы обсудить - я буду рад написать пиар.

@nrc @alexcrichton

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

Я согласен с @eddyb в том, что если все, что мы хотим, - это обрабатывать атрибуты, в интересах удобства и целесообразности мы должны просто расширить атрибуты.

Но если бы мы _did_ хотели более гибкую систему расширений, я предполагал, что мы будем использовать черты характера, но эти черты будут определены как набор методов, которые не относятся к Self :

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

Затем вы бы реализовали его на фиктивном типе, таком как struct my_annotation_type; (с тем же именем, что и атрибут, я думаю?), И мы использовали бы разрешение признака для извлечения соответствующих функций, таких как <my_annotation as CustomDerive>::foo (возможно, при записи метаданных, наверное). Дело в том, что мы никогда не создадим (или не будем нуждаться) в экземпляре my_annotation , это просто механизм группировки для объединения нескольких связанных функций.

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

Что касается пространств имен, @sgrif представляет собой хороший пример с примерами #[cfg] и cfg! . Я, конечно, могу представить, что кто-то хочет #[derive(SomeTrait)] а также имеет какой-то макрос, например SomeTrait! { ... } который ... что-то делает. =) Но @jseyfried также является хорошим аргументом в пользу обратной совместимости - пока мы не сталкиваемся с ограничениями _already_.

По умолчанию я предпочитаю меньшее количество пространств имен, в основном из-за боли, которую, как мне кажется, приносит нам разделение пространства имен значение / тип. Тем не менее, я думаю, что большинство известных болевых точек здесь не применимы:

• разделение типа / значения является проблемой при разрешении имен, потому что use foo::bar может импортировать или не импортировать модуль с именем bar и, следовательно, может (или не может) иметь отношение к разрешению имен, например bar::baz ;
• разделение типа / значения - это своего рода боль для дженериков по сравнению с константами, хотя эта боль также связана с синтаксическим разделением между типами и значениями.

Но в значительной степени, с тех пор как мы перешли мост, я не уверен, что наличие «custom derive», живущего в собственном пространстве имен, создает какие-то особые проблемы, не так ли?

Мы могли бы добавить префикс derive_ к сгенерированным макросам, чтобы сделать их псевдо-пространством имен. Если бы мы хотели внести это изменение, сейчас самое время.

@keeperofdakeys Разве это не эквивалентно тому, что авторы пользовательских производных решают назвать свои пользовательские производные derive_* ? Тем не менее, я считаю, что имена derive_* слишком уродливы для конечных пользователей.

@nikomatsakis

Но в значительной степени, с тех пор как мы перешли мост, я не уверен, что наличие «custom derive», живущего в собственном пространстве имен, создает какие-то особые проблемы, не так ли?

Алгоритм разрешения импорта может обрабатывать произвольно много пространств имен, но он выполняет потенциально нетривиальный объем работы для каждого пространства имен. В частности, для каждого импорта I и каждого неиспользуемого пространства имен S это доказывает, что разрешение I не выполняется в S (cf https: // github. com / rust-lang / rfcs / pull / 1560 # issuecomment-209119266). Это доказательство часто требует DFS графа импорта глобуса (в котором вершины являются модулями, а ребра - импортами глобусов) для поиска соответствующих неопределенных операций импорта.

Однако эта дополнительная работа с пространством имен может не иметь значения на практике, и ее можно избежать при необходимости (см. Https://github.com/rust-lang/rfcs/pull/1560#issuecomment-209119266) за счет незначительное ограничение, которое будет применяться только к пространствам имен макросов.

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

@nikomatsakis

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

@alexcrichton, как я, кажется, писал раньше, я рад подождать, пока нам понадобится больше мощности (если когда-либо) - и тогда мы сможем сделать что-то вроде черты, которую я описал, или, может быть, что-то получше. На данный момент я думаю, что достаточно было бы просто расширить атрибуты, применяемые к fn .

Мне стало любопытно, и я начал базовую реализацию этой идеи (используя атрибут в функции proc_macro для обозначения имен атрибутов, которые должны быть помечены как используемые в элементе).

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

Вопрос 1. Могут ли настраиваемые макросы изменять элемент, по которому они проходят?

• Никто не думает, что они должны делать это _ на практике_, конечно
• Это еще один режим, который изначально был отвергнут в духе ЯГНИ.
• Производные, которые изменяют набор имен полей и т. Д., Не компилируются должным образом, делая видимым порядок приложения;
  опасность этого смягчается двумя вещами:
  
  
  
  • Изменение имен / типов полей не может быть сделано прозрачно
  
  
  • Макросы, критичные для безопасности, могут использовать полностью явные шаблоны структуры, чтобы проверить, что никто не изменил набор полей.
  
  
• С другой стороны, если мы говорим, что custom derive нужно вернуть только новые impls
  
  
  
  • информация о диапазоне лучше
  
  
  • кастомные производные проще писать
  
  
• _Но_ многие настраиваемые производные используют настраиваемые атрибуты для управления своим расширением, и они будут генерировать предупреждения / ошибки.
  
  
  
  • Текущая техника состоит в том, чтобы удалить их из AST.
  
  
• _Также: _ мы хотим выпустить это в мир как можно скорее, не хотим проводить длительные эксперименты или радикальные изменения

Предложения:

• Оставьте все как есть, возможно, прекратите использование позже
  
  
  
  • Целесообразно, несколько неудачно
  
  
• Расширить #[proc_macro] белым списком атрибутов, указать rustc считать их "использованными" и игнорировать.
  
  
  
  • Простой, охватывает основной вариант использования
  
  
  • Но кому-то нужно это реализовать ( может быть, @keeperofdakeys! )
  
  

Вопрос 2: должны ли настраиваемые производные использовать то же пространство имен, что и другие макросы?

Аргумент за:

• меньше пространств имен, как правило, лучше, сокращает время выполнения разрешения
• обратная совместимость , позже нельзя удалить пространства имен
• правила использования заглавных букв ( #[derive(Foo)] vs foo! ) уже служат цели
• use foo::Bar любом случае не может различить, какое пространство имен вы имеете в виду, поэтому меньше места для путаницы, если они не разделяют

Аргумент против:

• #[cfg()] vs cfg!() происходит сегодня (но ни один из них не является настраиваемым производным, и это можно сделать, указав макросу контекст, в котором он выполняется )
• с точки зрения _пользователя_, вряд ли вас запутает,

Предложения:

• Разделить на пространство имен "custom derive"
• Сохраняйте статус-кво

Другие вещи?

Есть ли еще открытые вопросы?

Возможное решение проблемы мутации:

Вместо пользовательских производных с типом TokenStream -> TokenStream , они будут иметь тип
Item -> TokenStream , где Item - непрозрачный тип, который может начинаться всего двумя методами:

• item.tokens() , который возвращает TokenStream , которые будут переданы сегодня, и
• item.use_attrs(name) , который пометит все атрибуты с заданным именем как используемые.

Возвращенный TokenStream будет включать только производные impl s.
В конечном итоге мы могли бы добавить к API Item с удобными функциями (например, итерацией по полям / вариантам элемента) или API получения более высокого уровня, подобным тому, который содержится в syntax_ext::deriving::generic .

Я был бы рад реализовать разрешающие атрибуты из белого списка в #[proc_macro_derive] (т.е. второе предложение для вопроса 1 в https://github.com/rust-lang/rust/issues/35900#issuecomment-258315395) или мое предложение Item -> TokenStream .

Я думаю, что было бы ошибкой стабилизировать пользовательские производные, которые могут изменять базовый элемент. Информация диапазона, которой мы жертвуем, допуская мутацию, уже вызывает проблемы - например, нам нужно выбирать между исправлением # 37563 и исправлением # 36218.

Я действительно не вижу привлекательности императивного белого списка, может ли кто-нибудь придумать вариант использования?

Я не уверен, намеренно / желательно, чтобы этот код компилировался:

#![feature(proc_macro)]

#[proc_macro_derive(Whatever)]
struct Foo {}

@eddyb Я не уверен, есть ли неотъемлемая привлекательность императивного белого списка - я думаю, что преимущество
Item -> TokenStream заключается в том, что проще расширить API Item , чем добавлять больше видов декларативных атрибутов. При этом, если подумать об этом еще раз, может быть не так много других вариантов использования, для которых требуется Item вместо TokenStream , поэтому TokenStream -> TokenStream с декларативным белым списком может быть лучше.

Заменят ли макросы 2.0 этот API? В таком случае расширяемость не вызывает особого беспокойства, а Item -> TokenStream api не кажется очень привлекательным.

@keeperofdakeys Согласно RFC:

В целом, это следует рассматривать как постепенный шаг к официальным «макросам 2.0».

Задача макроса 1.1 - максимально приблизиться к макросу 2.0 по духу и реализации, но без стабилизации огромного количества функций. В этом смысле цель состоит в том, чтобы при наличии стабильного макроса 1.1 мы могли наложить обратно совместимые функции, чтобы перейти к макросу 2.0.

https://github.com/rust-lang/rfcs/pull/1681#issuecomment -233449053 и https://github.com/rust-lang/rfcs/pull/1681#issuecomment -233708395 и https: // github. com / rust-lang / rfcs / pull / 1681 # issuecomment -239558657, похоже, указывает на то, что прекращение поддержки. В частности: «шаблон дерева токенов с привязкой к строкам стал бы нежелательным, если бы фактически не стал устаревшим».

@eddyb

Я действительно не вижу привлекательности императивного белого списка, может ли кто-нибудь придумать вариант использования?

Что ж, я могу представить себе случай, когда имена атрибутов каким-то образом динамически генерируются (возможно, на основе имени типа или полей?) - и, следовательно, их нельзя объявить заранее. Хотя это кажется искусственным и не очень хорошей практикой.

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

Конечно, часть этого также будет поступать (_в конце концов_) из некоторой формы стандартного API AST.

Замечание о сроках: я очень, очень хочу увидеть стабилизацию макроса 1.1 в следующем цикле. То, что нам мешает, кажется, в конечном счете, довольно незначительным.

В этом духе мой взгляд на проблемы, которые я описал:

1. Я доволен либо декларативным расширением #[proc_macro] _, либо изменением типа на Item . Я также думаю, что, что бы мы ни выбрали, мы потенциально могли бы принять другое в будущем, если бы это казалось хорошей идеей. Я как бы хочу пойти с тем, что будет реализовано первым. знак равно
2. Что касается нескольких пространств имен, я думаю, что мы должны пока держать их в одном пространстве имен. Для меня сочетание обратной совместимости (то есть, сохранение наших возможностей открытыми) с тем фактом, что использование заглавных букв уже отличает макросы «настраиваемого извлечения» от других на практике, является убедительным. Отличие #[cfg] от cfg! кажется чем-то, с чем мы могли бы справиться другими способами, или, если мы хотим, мы можем ввести разделенные пространства имен _then_. Не похоже, что наличие единого пространства имен вредит, в частности, варианту использования настраиваемого наследования, и это единственное, о чем мы говорим в любом случае о стабилизации. Правильно?

@nikomatsakis, ваше резюме звучит точно, спасибо, что написали его! Мне жаль, что мы не получим макрос 1.1 в Rust 1.14, но я понимаю, что это спорные вопросы.

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

Я не совсем следую Item -> TokenStream API, возвращаемый поток токенов по-прежнему охватывает исходный элемент или только добавленные имплименты? Значит ли это, что потребуется &mut Item ?

@ est31 ваш комментарий звучит как ошибка, можете ли вы открыть для этого отдельный вопрос?

Я почти полностью согласен с комментарием

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

Проблема возникла из-за того, что он сломал дизельное топливо, в котором в настоящее время есть макросы, называемые, например, Queryable! которые вы можете обернуть структуру, чтобы получить для нее Queryable .

Как человек, который прямо сейчас не использует и не обслуживает дизельное топливо (то есть как человек, на которого не влияет то, что я собираюсь предложить: sweat_smile :), я думаю, что лучше всего сохранить 1 пространство имен на данный момент, а для дизеля изменить название эти макросы на derive_Queryable! или что-то в этом роде. Они будут устаревшими, когда это будет стабильно, верно?

Я создал PR https://github.com/rust-lang/rust/pull/37614 для предлагаемой функции. Он использует отдельный атрибут #[proc_macro_attributes(..)] , и вам больше не нужно возвращать элемент в возвращенном TokenStream .

Я подал # 37637, чтобы выяснить, как макросы proc должны обрабатывать $crate .

Просто чтобы уточнить, считается ли этот вариант использования правильным или неправильным использованием системы:

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

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

@TheNeikos

Основное обратно несовместимое изменение будет заключаться в том, что вы больше не сможете изменять элемент (вы не передаете его обратно в TokenStream). Я бы сказал, что получение чего-либо, кроме имп, не предназначено, но ничто не мешает вам это сделать. Вам просто нужно быть осторожным с конфликтами имен.

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

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

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

@TheNeikos @sgrif Моя точка зрения состоит в том, что все, что серьезно изменяет ввод, не является производным и, следовательно, не предназначено для рассмотрения здесь. Я думаю, что использование настраиваемых производных для макросов процедур общего назначения несколько опасно (отсутствие гигиены и т. Д.), Поэтому я не стремлюсь поощрять это.

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

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

С точки зрения того, что я считаю идиоматическим; Я думаю, что создавать новые типы - это нормально, но гораздо лучше, если эти типы связаны с типом, который вы выводите. Например, представьте, что если бы мы могли получить IntoIterator для типа, это потребовало бы создания структуры Iterator . По идее, вы должны определять поведение для этого типа, но это поведение может не быть «имплицитной чертой».

@sgrif

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

Хм, я определенно сочувствую, хотя, очевидно (как заметил @nrc ), это не то, для чего была разработана система, и она будет иметь тенденцию обнажать различные острые углы. Вероятно, это не имеет значения для ваших вариантов использования. Я предполагаю, что ключевой вопрос заключается в том, как быстро мы сможем перейти к чему-то вроде "макросов взрыва 1.1".

PR был объединен, поэтому вы сможете увидеть следующие изменения в следующий вечер. Функция proc_macro_derive больше не должна возвращать элемент (это вызовет ошибку о том, что тип определен дважды), и теперь вы можете предоставить список имен атрибутов в белый список, например #[proc_macro_derive(Derive, attributes(Foo, Bar)] .

cc @dtolnay , @sgrif ^

К сожалению, это скоро вызовет поломку

Да, я подал https://github.com/serde-rs/serde/issues/614, чтобы отслеживать на нашей стороне.

Я думаю, что исправил поломку в Diesel в https://github.com/diesel-rs/diesel/pull/493 , буду знать наверняка, когда снова будут строить ночные клубы.

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

У меня есть макрос #[derive(newtype)] proc в моем (крошечном, неопубликованном) ящике, который расширяется до другого набора других #[derive()] s в зависимости от структуры, которую он аннотирует. Например, #[derive(newtype)] struct Foo(u64) заменяется на #[derive(Clone, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)] struct Foo(u64); тогда как #[derive(newtype)] struct Foo(::semver::VersionReq) заменяется на #[derive(Clone, Debug, PartialEq)] struct Foo(::semver::VersionReq); . Таким образом, члены структуры не изменяются этим макросом, но к нему добавляются другие производные (они также не изменяют структуру).

Таких структур несколько десятков, и у каждой есть около десяти новых производных после расширения этого макроса. Мне это нравится, если я понимаю, что хочу, чтобы все типы u64 newtypes реализовывали еще одну черту, я могу просто изменить набор производных в одном месте в коде макроса newtype вместо каждой отдельной структуры.

Раньше у меня был макрос macro_rules newtype! для этого, но я переключился на макрос proc, потому что:

• Наличие или отсутствие комментариев к документу, наличие или отсутствие pub и т. Д. Обрабатываются бесплатно, не требуя комбинаторного количества плеч макроопределения.
• Даже если бы я написал комбинаторные макро-соответствующие руки, было сложно найти такой порядок, при котором они не конфликтовали бы друг с другом.

К сожалению, нет, вы больше не можете делать это так, как раньше.

Что касается будущей совместимости этой функции, находящейся в стабильном состоянии: поскольку функция плагина не должна быть «чистой», будет ли это критическим изменением, если порядок объектов, переданных функции, будет изменен в будущем, или если rustc реализует многопоточность компиляция?

@ est31 Если у нас есть время, мы должны попытаться снять упомянутую выше изоляцию IPC.

Я постоянно вижу ДВС в дизеле после самых последних изменений.

../src/librustc_metadata/decoder.rs:490: запись: id не найден: DefIndex (1) в ящике "diesel_codegen" с номером 28

@sgrif , это будет проблема # 37788, которая будет исправлена ​​с помощью # 37793 (будем надеяться, что она закончится завтра вечером ...).

@ est31 В этот час уже слишком поздно, чтобы объединить его до начала ночной сборки.

https://github.com/rust-lang/rust/issues/37839 - проблема с использованием контейнера lib, который сам использует ящик proc_macro. AFAICT ни один из тестов не затронут этим, потому что они либо компилируют только макромодуль proc, либо модуль макроса proc и модуль bin, которые напрямую ссылаются на макрос proc.

Изменить: теперь исправлено!

@Arnavion Проблема, которую вы видели с # 37839, исправлена ​​для обычных осложнений, но остается неисправной при использовании --target , как сообщается в # 37958. Я предоставил минимальный тестовый пример с использованием --target который все еще не работает.

@rfcbot fcp слияние

Теперь, когда реализована функция добавления атрибутов в белый список, я думаю, мы должны это стабилизировать! Serde, Diesel и другие пользователи - теперь вы можете изменить объект, если текущий дизайн вам не подходит. знак равно

cc @sgrif @erickt

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

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

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

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

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

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

@rfcbot просмотрел

В настоящее время, если TokenStream не может проанализировать, возвращается пустая ошибка LexError . Можно ли было бы вернуть здесь более точное сообщение об ошибке, например, какой токен не удалось проанализировать? Хотя пользователи вашей библиотеки, вероятно, не хотят видеть такие сообщения об ошибках.

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

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

На https://github.com/rust-lang/rust/pull/38140 мы заставляем объявления настраиваемого наследования быть общедоступными. Теория состоит в том, что однажды нам могут потребоваться частные производные, а затем мы, вероятно, захотим провести это различие на основе видимости определяющей функции. В любом случае это консервативный выбор. Я подумал, что оставлю его мариноваться на день или два, чтобы люди увидели его перед слиянием, поскольку мы стабилизируем эту функцию.

№37480 закрыт, что должно быть отражено в чек-листе.

Исправлена

@pnkfelix Я взял на себя смелость

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

psst @nikomatsakis , мне не удалось добавить метку final-comment-period , сделайте это.

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

Прямо сейчас их два:

• # 36935 содержит комментарий о том, что проблема решена.
• # 36691 мне не кажется блокирующим, мы можем позволить им расшириться до mod foo; когда-нибудь в будущем, если захотим, не нарушая ничего, как мне кажется.

Привет! Это аудит документации RFC 1636 . Это первая важная функция, которая стабилизируется с момента принятия RFC 1636, и в этом случае мы должны как следует поработать над его соблюдением.

RFC гласит:

Перед стабилизацией функции теперь она будет задокументирована следующим образом:

• Возможности языка:
  
  
  
  • должен быть задокументирован в Справочнике по Rust.
  
  
  • должны быть задокументированы на языке программирования Rust.
  
  
  • может быть задокументирован в Rust на примерах.
  
  
• Изменения как языковых функций, так и стандартной библиотеки должны включать:
  
  
  
  • одна строка для журнала изменений
  
  
  • более подробное описание объявления о выпуске в полной форме.
  
  

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

cc @ rust-lang / docs

Спасибо @withoutboats ! Да, это первая серьезная проблема. У меня было это в моем списке, чтобы посмотреть сегодня утром, и вот, ты меня опередил 😄

Я всегда представлял себе это так, что решение о стабилизации и фактическая стабилизация разделены. То есть @ rust-lang / lang может сказать «это можно сделать стабильным», но фиксация на удаление шлюза также гарантирует, что документация существует. В мире, где существует нестабильная книга , это перетащит документы оттуда в стабильные документы; но до тех пор все немного неудобно.

Учитывая, что у нас только что был релиз, я планировал сделать что-то вроде этого:

1. Подождите, пока это оставит FCP
2. Приложите несколько документов. (Я планировал написать их в этом случае)
3. Сделайте стабилизацию ПР.

Возможно сочетание двух и трех.

/ cc @ rust-lang / core, поскольку это межгрупповая проблема.

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

Также было бы неплохо получить их быстро, чтобы мы могли обеспечить безопасный обратный перенос в бета-версию 1.15!

Если я первый, кто ударит это, это не может быть так уж плохо, но давайте включим его в список известных ошибок: использование макроса типа внутри структуры с настраиваемой производной вызывает ICE https://github.com/rust-lang/ ржавчина / вопросы / 38706

https://github.com/rust-lang/rust/pull/38737 исправляет макросы типа ICE: heart :. Есть ли шанс перенести это на бета-версию? Обоснование: кажется плохим, что две выдающиеся новые функции, одна из которых выпущена в версии 1.13, а другая в версии 1.15, приводят к сбою компилятора при их совместном использовании.

Я только что создал # 38749, касающийся документации ящика proc_macro .

Я несколько раз читал, что макросы 1.1 будут стабилизированы в версии 1.15, но 1.15.0-beta.1 была выпущена две недели назад, и по крайней мере extern crate proc_macro; все еще поддерживается в нем, как и в ночном 4ecc85beb 2016 -12-28. Планируется ли резервное копирование изменения стабилизации?

@SimonSapin: да, это был план, но нам нужно, чтобы это произошло!

Это все еще план: p

Если пользователь пишет #[derive(Foo)] #[foo_def = "definition.json"] struct MyStruct; обработчик макроса не имеет возможности узнать, что такое «текущий каталог», и поэтому не может найти definition.json .

Это сделано намеренно, и поэтому исправить это будет непросто, и я думаю, что уже слишком поздно исправлять это.

Вы можете перейти в Span -> FileMap -> имя файла -> каталог. Все, чего не хватает, - это доступа к информации через proc_macro .

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

Макрос proc может использовать env::var("CARGO_MANIFEST_DIR") для получения каталога, содержащего Cargo.toml ящика, содержащего вызов макроса. Предположительно foo_def относительно этого. См. Https://github.com/dtolnay/syn/issues/70#issuecomment -268895281.

@tomaka, что можно сделать путем изменения FileMap, например, так делает это макрос include_str! .

Предположительно foo_def относится к этому.

Я думаю, что указывать путь относительно Cargo.toml не очень интуитивно.

это можно сделать, изменив FileMap, например, так include_str! макрос делает это.

Да, я знаю, что это можно сделать, но этого просто нельзя сделать с текущим API процедурных макросов.

Параметр - Item . Было бы приемлемо добавить метод для получения диапазона из этого элемента, но добавление метода к Item чтобы попросить компилятор добавить зависимость, было бы взломом IMO.

Вы можете перейти Span -> FileMap -> filename -> directory.

Эти API (в частности, FileMap ) находятся на пути к стабилизации?

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

Я только что получил эту ошибку в своем ящике. Что происходит?

`` error: Cannot use #! [Feature (proc_macro)] and #! [Feature (custom_attribute)] одновременно
`` ''

@alexreg Если вы используете #[derive] , теперь он стабилен. Вам не нужно #![feature(proc_macro)] .

@alexreg
proc_macro_derive s (макросы 1.1) теперь стабильны - вы можете просто удалить #![feature(proc_macro)] .

#[proc_macro_attribute] недавно приземлился за воротами функции #![feature(proc_macro)] ; они несовместимы с #![feature(custom_attribute)] . #![feature(custom_attribute)] будет считаться устаревшим после установки замены (https://github.com/rust-lang/rfcs/pull/1755).

@jseyfried Я думаю, нам следует изменить проблему отслеживания на proc_macro поскольку она закрыта и не содержит соответствующей информации.

Спасибо ребята. В этом есть смысл.

@abonander Да, #![feature(proc_macro)] определенно должен указывать на # 38356 - я должен был убедиться в этом при просмотре # 38842. Не могли бы вы подать PR?