rust building blocked что делать
Building decaying Rust – Что делать?
Новички часто не знают, что делать в Rust, если видят надпись «Building decaying». В правом нижнем углу экрана она светится красным цветом. Логика вещей подсказывает, что такие сообщения не могут предвещать ничего хорошего по своей природе. Вы столкнулись с проблемой, и её нужно решать.
Переводится эта надпись, как «разложение строения». Так это звучит дословно. Адаптированных версий перевода может быть много. Мне больше всего нравится «гниение постройки». То есть, то здание, которое вы построили для жилья при условии, что внутри стоит шкаф с инструментами, постепенно разваливается. Если шкафа не будет, сообщения вы не увидите, но постройка, тем не менее, продолжит гнить.
Раньше (пару лет назад) процесс гниения был необратим. Каждый день вы обязательно должны были заходить в игру, чтобы отремонтировать гниющие элементы своей базы. Это была абсолютно необходимая профилактика. Исключения составляли лишь те сервера с модами, где устанавливался плагин «Nodecay». Он существует и по сей день, но уже ни так популярен, потому что разработчики сами решили проблему.
Как вы знаете, в игре есть шкаф с инструментами. Это довольно большая деревянная коробка, похожая на холодильник, установка которой запрещает неавторизованным в ней игрокам строиться в радиусе пятидесяти метров. Раньше шкаф нужен был исключительно для блокировки строительства. То есть, банально для того, чтобы к вашему дому никто не смог подстроиться и начать рейдить с крыши или, что ещё хуже, чтобы рейдер просто не залез в окно на втором этаже.
Сегодня в шкаф можно складывать любую разновидность ресурсов, начиная от угля, заканчивая металлом высокого качества. Зачем это придумано? Чтобы предотвращать гниение! Вы складываете в шкаф те ресурсы, из которых построен ваш дом, и он прекращает разваливаться, а надпись «Building decaying» пропадает из поля зрения.
Если вы загляните внутрь шкафа, там вас сообщится, что именно и в каком количестве необходимо, чтобы предотвратить гниение на одни реальные сутки, то есть, на 24 часа. Чем больше ваше строение, тем оно прожорливее. Содержать огромные замки невыгодно.
Building decaying в Rust. Что делать?
Предположим, вы построили дом из камня, установили в нём железные двери и деревянные решётки на окнах. Если положить в шкаф только камень, забыв о дереве и железе, спустя час – полтора реального времени решётки с дверями сломаются. Случиться это может, кстати говоря, прямо на ваших глазах. Если будете внутри дома или поблизости, услышите характерный треск.
После улучшения постройки до уровня камня или железа, кладите в ящик запас соответствующего ресурса, которого хватит на месяц. Учтите, если захочется расшириться, лучше проверьте, как это повлияет на потребность в ресурсах. Возможно, вы сократите время жизни постройки с месяца до одного дня, если расширитесь кардинально.
Шкаф лучше прятать за дверями. Если вы играете на сервере без модов или без плагина «Remove», то за стенами его, понятное дело, лучше не прятать. Особенно, если планируется расширение или привлечение других игроков для создания команды. Без авторизации в ящике они ничего не смогут делать в вашем доме, даже поставить костёр будет невозможно.
Погружаемся в логово ржавчины. Как работает компилятор rust
В моей предыдущей статье о rust я попытался рассказать об истории языка, и показать откуда он пришёл. В статье было сделано множество упрощений. Просто нереальное множество. Народу не понравилось. Но в опросе, в конце статьи вы сказали, что надо бы показать кишки компилятора. Ну что же, под катом вы найдёте разбор исходных кодов компилятора rust. Мы проследим путь программы, начиная из исходного файла, прямиком к бинарнику.
Словарь
ICE (Internal compiler error), ошибка компилятора.
Дальнейший текст подразумевает, что вы умеете программировать. Можно и не на rust.
Начало
Поехали. Мы будем лезть нашими ручками в сам компилятор и смотреть на его исходники. Для начала нам понадобятся кое-какие инструменты. Ставим чистую виртуальную машину с Windows 10. Идём в интернеты и льём следующее:
Сорцы компилятора. Достаются с github. Можно лить просто zip, ибо обратно коммитить мы ничего не будем.
Установщик компилятора. Любая свежая стабильная версия подойдёт.
Guide to Rustc Development. Инструкция по разработке компилятора. 460 страниц. Не хило. Сохраняем pdf.
Ну и хорошо. Этого, для начала достаточно. Отключаемся от проводного интернета, хватаем ноутбук и идём на веранду, сидеть и погружаться. Начинаем погружаться, понимаем что будет глупо говорить о компиляторе, если мы не скомпилируем хоть что-то. Ок, так и сделаем.
Ок, это было просто. Но мы не будем использовать cargo для самой компиляции. Используем компилятор напрямую. Но я же на надо cargo издеваюсь, так ведь?
Отступление по теме
Как не надо устанавливать rust
Чего? Так, сам по себе компилятор всё собрал, но ругается на отсутствие линкера. От жеж, зараза. То есть, линкер ему нужен внешний. Ругаемся на компилятор, встаём с удобного кресла и идём обратно, подключаться к проводному интернету, потому что палить 5 гигов установщика Visual Studio Build Tools не хочется на хотспоте.
Билдим всё ещё раз и смотрим.
Ширина и жирина файлов.
Ах, ты, ржавая банка! Какого чёрта?? Я уже как две недели рассказываю всем обитателям Хабра о том, какой ты прекрасный компилятор, и как хорошо ты собираешь минимальные бинарники, а ты. 150 килобайт исполняемого кода из-за одной только линии текста на экране?
Ус недоволен. На него и так уже много чего намотано, он не понимает, почему ему надо разбираться с исходниками раста теперь.
Шаг первый: rustc
Открываем сорцы и наслаждаемся. Всё выглядит очень прилично и чисто. Тут, понятное дело, можно учиться тому как правильно разделять свой проект на куски и как правильно управлять кодом на rust. Собственно говоря, сразу понятно куда идти. Забираемся в compiler/rustc/src/main.rs и смотрим.
Всё только начинается. Держитесь.
Хм. То есть точка входа в программу просто тянет jemalloc вызовы и запускает ещё две функции. Ну вот, всё. Теперь понятно как работает компилятор rust. Делов-то! Кстати, jemalloc это специальный менеджер памяти, изначально разработанный для FreeBSD в 2005 году. Основной упор был сделан на то, чтобы избежать фрагментации памяти при работе с этим аллокатором. В оригинальной версии он просто заменяет malloc. В 2007 году Firefox начал использовать этот менеджер для снижения расхода памяти, а ещё через пару лет он попал в Facebook.
Шаг второй: rustc-driver
Ладно, всё выглядит слишком уж просто. Погружаемся дальше. rustc тянет за собой rustc-driver. Ныряем туда.
Тут мы найдём небольшой readme, который расскажет нам о том, что компилятора в самом драйвере мы не найдём. Эта программа собирает конфигурацию из аргументов и запускает сам процесс компиляции из других крейтов. После изучения исходников находим функцию для запуска процесса компиляции.
Да, в этом крейте файлов не так-то много, но что бы тут не творилось, на самом деле всё сводится к вызову методов в крейте под названием interface. Вышеприведённый код это и показывает. interface::run_compiler и поехали.
Что же произошло в rustc-driver? Мы собрали все конфиги. Подгрузили все файлы и нашли их местоположение в файловой системе. Создали замыкание, которое следит за процессом компиляции и запускает линкер после успешной компиляции. Запустили линтеры (если такие имелись) и приготовили сам компилятор к запуску. Давайте запускать.
Шак третий: rustc-interface
Ага. Тут мы уже ближе к самому процессу компиляции. Все конфиги подъедены, файлы тоже замеплены. Смотрим на исходники интерфейса. Их хоть и не так-то много, но это наш центральный вокзал, где куча других крейтов собирается воедино.
Так, осматриваемся и находим
Кстати тут же, недалеко, мы можем найти настройку механизма кодогенерации.
Быстренько посмотрим на наши сорцы и увидим что у нас прямо в сорцах есть 3 различных модуля кодогенерации. Что они делают? Превращают MIR в конечный код для системы компиляции. Открываем rustc-codegen-llvm и смотрим в README:
Ок, ну тут всё понятно, мы берём MIR и переделываем его в LLVM IR. После этого LLVM может скомпилировать код в конечный бинарник. Но погодите, помимо LLVM бекенда у нас есть ещё два других! Смотрим туда. rustc-codegen-ssa согласно документации, позволяет генерировать низкоуровневый код, который не будет привязан к определённому бекэнду (например, LLVM) и позволит в дальнейшем использовать другие системы компиляции.
Собственно говоря, прямо там же вы найдёте rustc-codegen-cranelift. То есть MIR в будущем может компилироваться через cranelift, который в идеале ускорит процесс компиляции. Ну это в будущем, пока что проект в процессе тестирования и работает не лучше, чем Газель без мотора.
Открываем модуль и смотрим, что происходит внутри:
Ага, вот тут мы берём быка за рога и начинаем разбирать исходный код на части. Далее, создаём и проверяем AST
Даже если вы и поменяли что-то в каком-либо файле, то благодаря системе запросов вы сможете избежать ненужной перекомпиляции. Что если вы изменили только одну линию в комментариях к файлу? Пересобирать такой не придётся.
Давайте посмотрим на запросы, которые создаёт компилятор:
В итоге у нас на выходе получается большая и толстая структура:
И как раз её можно дёргать для выполнения необходимых запросов.
Шаг четвёртый: rustc-parse и rustc-lexer
Далее по тексту вы найдёте простую логику всех этих запросов. «Простая» логика заключается в вызове крейтов, которые её обрабатывают. Например, rustc-parse. Это крейт, который использует rustc-lexer. Лексер читает строки из файлов и преобразовывает их в очень простые токены. Токены передаются парсеру, который превращает их в Span и продолжает работу с кодом. Основной момент этого Span заключается в том, что к каждому элементу в дереве кода будет добавлена информация о том, в каком конкретно месте этот элемент записан в исходном файле. Когда компилятор будет сообщать об ошибке, вы увидите, где именно эта ошибка произошла.
Шаг пятый: rustc-expand
В результате работы парсера мы получаем наш самый великий и могучий AST.
Всё это создаётся огромным макросом astfragments! в \compiler\rustcexpand\src\expand.rs
AST используется для дальнейшей генерации кода и приведения его в нужный вид. Про это можно писать отдельную книгу. Но мы пока удовольствуемся там, что AST можно разобрать до HIR.
Шаг шестой: rustc-middle
Этим как раз и занимается rustc-middle. Вернее, не только этим. Залезаем в исходники и видим что тут у нас есть HIR, MIR и Types.
Здесь весь синтаксический сахар растворяется в чае и перестаёт быть сахаром. Так моя любимая for node in data превращается в
С HIR теперь можно работать…
Шаг седьмой: rustc_ty
Последняя тянется через весь процесс компиляции.
Файл просто огромный. Нам надо вычислить типы каждой переменной, замыкания и трейта. Сам модуль занимает более 3000 строк, не считая остальные файлы в директории.
Кстати, смотрим в rust-master\compiler\rustc_typeck\src\check\expr.rs
Компилируем и запускаем:
Пасхалки они выглядят именно вот так.
Так, вычислили типы и теперь можем проверить что никто не пытается запихнуть строку в Int. Хорошо. Можно идти дальше.
Шаг восьмой: rustc_mir и rustc_mir_build
Теперь наш HIR можно преобразовать в MIR. Берём ранее созданный TyCtxt и начинаем преобразовывать его в
И так далее по всем нодам. MIR это намного более генерализированная версия HIR. Она очень близка к тому что требует от нас LLVM для компиляции. В результате этой генерализации мы можем намного более эффективно работать над оптимизацией написанного вами кода и заниматься проверками заимствований и оптимизацией.
Шаг девятый: Проверка заимствования
Самая «страшная» функция rust это всем известный borrow cheker. Сам он живёт в
Шаг десятый: Оптимизации
Шак одиннадцатый: прощай, rust!
Полученный оптимизированный MIR можно теперь переделать в LLVM IR. Поехали. rustc-codegen-llvm создаёт LLVM-IR на базе MIR, который мы сгенерировали на предыдущем этапе. Здесь заканчивается rust и начинается llvm. Хотя, мы ещё не закончили с сорцами компилятора.
Копаемся чуть глубже и находим rustc-target в котором видим различные дополнительные классы для работы с определённым ассемблером.
После того как кодогенерация завершена, мы можем передать IR в сам LLVM. rustc_llvm нам в помощь.
Вот, собственно говоря, и всё, ребята! LLVM за пределами нашей видимости. На моей операционной системе Visual Studio Build Tools берут на себя контроль и перегоняют LLVMIR в обычный бинарник.
Он парсится из текста в AST.
AST обрабатывается и оптимизируется в HIR
HIR обрабатывается и оптимизируется в MIR.
MIR делает проверки заимствования и оптимизацию и перегоняется в LLVMIR.
LLVMIR компилируется на конечной платформе.
Пробуем ручками
Ну что же, напоследок осталось написать простенькую программку, типа этого:
И начать её компилировать, только показывая все внутренности. Для начала есть замечательная опция компилятора, которая работает на любой версии:
Значит, запуская компиляцию следующим образом:
Мы получаем на выходе мириады различных форматов, включая сгенерированный ассемблеровский код, байткод и IR для LLVM, и даже челвоеко-читаемый MIR.
А если у вас есть nightly компилятор, то вы можете запустить
И полюбоваться вашим HIR, в то время как
Даст вам возможность посмотреть на то, как выглядит AST.
Напоследок
Ну что же, мы залезли в дебри компилятора. Теперь вы знаете, что происходит каждый раз когда вы запускаете билд на своей машине. Я показал вам rust. Но не бойтесь, ваш любимый язык, скорее всего, ничуть не менее сложен. Проще будет только компилировать ассемблер для 386 под досом. И не важно, если вы запускаете C#, Java, Javascript, Golang или haskell. Происходить будет многое, хотя и совсем по-разному.
Понятно? Ну и хорошо.
Постскриптум
Погружаемся в логово ржавчины. Как работает компилятор rust
В моей предыдущей статье о rust я попытался рассказать об истории языка, и показать откуда он пришёл. В статье было сделано множество упрощений. Просто нереальное множество. Народу не понравилось. Но в опросе, в конце статьи вы сказали, что надо бы показать кишки компилятора. Ну что же, под катом вы найдёте разбор исходных кодов компилятора rust. Мы проследим путь программы, начиная из исходного файла, прямиком к бинарнику.
Словарь
ICE (Internal compiler error), ошибка компилятора.
Дальнейший текст подразумевает, что вы умеете программировать. Можно и не на rust.
Начало
Поехали. Мы будем лезть нашими ручками в сам компилятор и смотреть на его исходники. Для начала нам понадобятся кое-какие инструменты. Ставим чистую виртуальную машину с Windows 10. Идём в интернеты и льём следующее:
Сорцы компилятора. Достаются с github. Можно лить просто zip, ибо обратно коммитить мы ничего не будем.
Установщик компилятора. Любая свежая стабильная версия подойдёт.
Guide to Rustc Development. Инструкция по разработке компилятора. 460 страниц. Не хило. Сохраняем pdf.
Ну и хорошо. Этого, для начала достаточно. Отключаемся от проводного интернета, хватаем ноутбук и идём на веранду, сидеть и погружаться. Начинаем погружаться, понимаем что будет глупо говорить о компиляторе, если мы не скомпилируем хоть что-то. Ок, так и сделаем.
Ок, это было просто. Но мы не будем использовать cargo для самой компиляции. Используем компилятор напрямую. Но я же на надо cargo издеваюсь, так ведь?
Отступление по теме
Как не надо устанавливать rust
Чего? Так, сам по себе компилятор всё собрал, но ругается на отсутствие линкера. От жеж, зараза. То есть, линкер ему нужен внешний. Ругаемся на компилятор, встаём с удобного кресла и идём обратно, подключаться к проводному интернету, потому что палить 5 гигов установщика Visual Studio Build Tools не хочется на хотспоте.
Билдим всё ещё раз и смотрим.
Ширина и жирина файлов.
Ах, ты, ржавая банка! Какого чёрта?? Я уже как две недели рассказываю всем обитателям Хабра о том, какой ты прекрасный компилятор, и как хорошо ты собираешь минимальные бинарники, а ты. 150 килобайт исполняемого кода из-за одной только линии текста на экране?
Ус недоволен. На него и так уже много чего намотано, он не понимает, почему ему надо разбираться с исходниками раста теперь.
Шаг первый: rustc
Открываем сорцы и наслаждаемся. Всё выглядит очень прилично и чисто. Тут, понятное дело, можно учиться тому как правильно разделять свой проект на куски и как правильно управлять кодом на rust. Собственно говоря, сразу понятно куда идти. Забираемся в compiler/rustc/src/main.rs и смотрим.
Всё только начинается. Держитесь.
Хм. То есть точка входа в программу просто тянет jemalloc вызовы и запускает ещё две функции. Ну вот, всё. Теперь понятно как работает компилятор rust. Делов-то! Кстати, jemalloc это специальный менеджер памяти, изначально разработанный для FreeBSD в 2005 году. Основной упор был сделан на то, чтобы избежать фрагментации памяти при работе с этим аллокатором. В оригинальной версии он просто заменяет malloc. В 2007 году Firefox начал использовать этот менеджер для снижения расхода памяти, а ещё через пару лет он попал в Facebook.
Шаг второй: rustc-driver
Ладно, всё выглядит слишком уж просто. Погружаемся дальше. rustc тянет за собой rustc-driver. Ныряем туда.
Тут мы найдём небольшой readme, который расскажет нам о том, что компилятора в самом драйвере мы не найдём. Эта программа собирает конфигурацию из аргументов и запускает сам процесс компиляции из других крейтов. После изучения исходников находим функцию для запуска процесса компиляции.
Да, в этом крейте файлов не так-то много, но что бы тут не творилось, на самом деле всё сводится к вызову методов в крейте под названием interface. Вышеприведённый код это и показывает. interface::run_compiler и поехали.
Что же произошло в rustc-driver? Мы собрали все конфиги. Подгрузили все файлы и нашли их местоположение в файловой системе. Создали замыкание, которое следит за процессом компиляции и запускает линкер после успешной компиляции. Запустили линтеры (если такие имелись) и приготовили сам компилятор к запуску. Давайте запускать.
Шак третий: rustc-interface
Ага. Тут мы уже ближе к самому процессу компиляции. Все конфиги подъедены, файлы тоже замеплены. Смотрим на исходники интерфейса. Их хоть и не так-то много, но это наш центральный вокзал, где куча других крейтов собирается воедино.
Так, осматриваемся и находим
Кстати тут же, недалеко, мы можем найти настройку механизма кодогенерации.
Быстренько посмотрим на наши сорцы и увидим что у нас прямо в сорцах есть 3 различных модуля кодогенерации. Что они делают? Превращают MIR в конечный код для системы компиляции. Открываем rustc-codegen-llvm и смотрим в README:
Ок, ну тут всё понятно, мы берём MIR и переделываем его в LLVM IR. После этого LLVM может скомпилировать код в конечный бинарник. Но погодите, помимо LLVM бекенда у нас есть ещё два других! Смотрим туда. rustc-codegen-ssa согласно документации, позволяет генерировать низкоуровневый код, который не будет привязан к определённому бекэнду (например, LLVM) и позволит в дальнейшем использовать другие системы компиляции.
Собственно говоря, прямо там же вы найдёте rustc-codegen-cranelift. То есть MIR в будущем может компилироваться через cranelift, который в идеале ускорит процесс компиляции. Ну это в будущем, пока что проект в процессе тестирования и работает не лучше, чем Газель без мотора.
Открываем модуль и смотрим, что происходит внутри:
Ага, вот тут мы берём быка за рога и начинаем разбирать исходный код на части. Далее, создаём и проверяем AST
Даже если вы и поменяли что-то в каком-либо файле, то благодаря системе запросов вы сможете избежать ненужной перекомпиляции. Что если вы изменили только одну линию в комментариях к файлу? Пересобирать такой не придётся.
Давайте посмотрим на запросы, которые создаёт компилятор:
В итоге у нас на выходе получается большая и толстая структура:
И как раз её можно дёргать для выполнения необходимых запросов.
Шаг четвёртый: rustc-parse и rustc-lexer
Далее по тексту вы найдёте простую логику всех этих запросов. «Простая» логика заключается в вызове крейтов, которые её обрабатывают. Например, rustc-parse. Это крейт, который использует rustc-lexer. Лексер читает строки из файлов и преобразовывает их в очень простые токены. Токены передаются парсеру, который превращает их в Span и продолжает работу с кодом. Основной момент этого Span заключается в том, что к каждому элементу в дереве кода будет добавлена информация о том, в каком конкретно месте этот элемент записан в исходном файле. Когда компилятор будет сообщать об ошибке, вы увидите, где именно эта ошибка произошла.
Шаг пятый: rustc-expand
В результате работы парсера мы получаем наш самый великий и могучий AST.
Всё это создаётся огромным макросом astfragments! в \compiler\rustcexpand\src\expand.rs
AST используется для дальнейшей генерации кода и приведения его в нужный вид. Про это можно писать отдельную книгу. Но мы пока удовольствуемся там, что AST можно разобрать до HIR.
Шаг шестой: rustc-middle
Этим как раз и занимается rustc-middle. Вернее, не только этим. Залезаем в исходники и видим что тут у нас есть HIR, MIR и Types.
Здесь весь синтаксический сахар растворяется в чае и перестаёт быть сахаром. Так моя любимая for node in data превращается в
С HIR теперь можно работать…
Шаг седьмой: rustc_ty
Последняя тянется через весь процесс компиляции.
Файл просто огромный. Нам надо вычислить типы каждой переменной, замыкания и трейта. Сам модуль занимает более 3000 строк, не считая остальные файлы в директории.
Кстати, смотрим в rust-master\compiler\rustc_typeck\src\check\expr.rs
Компилируем и запускаем:
Пасхалки они выглядят именно вот так.
Так, вычислили типы и теперь можем проверить что никто не пытается запихнуть строку в Int. Хорошо. Можно идти дальше.
Шаг восьмой: rustc_mir и rustc_mir_build
Теперь наш HIR можно преобразовать в MIR. Берём ранее созданный TyCtxt и начинаем преобразовывать его в
И так далее по всем нодам. MIR это намного более генерализированная версия HIR. Она очень близка к тому что требует от нас LLVM для компиляции. В результате этой генерализации мы можем намного более эффективно работать над оптимизацией написанного вами кода и заниматься проверками заимствований и оптимизацией.
Шаг девятый: Проверка заимствования
Самая «страшная» функция rust это всем известный borrow cheker. Сам он живёт в
Шаг десятый: Оптимизации
Шак одиннадцатый: прощай, rust!
Полученный оптимизированный MIR можно теперь переделать в LLVM IR. Поехали. rustc-codegen-llvm создаёт LLVM-IR на базе MIR, который мы сгенерировали на предыдущем этапе. Здесь заканчивается rust и начинается llvm. Хотя, мы ещё не закончили с сорцами компилятора.
Копаемся чуть глубже и находим rustc-target в котором видим различные дополнительные классы для работы с определённым ассемблером.
После того как кодогенерация завершена, мы можем передать IR в сам LLVM. rustc_llvm нам в помощь.
Вот, собственно говоря, и всё, ребята! LLVM за пределами нашей видимости. На моей операционной системе Visual Studio Build Tools берут на себя контроль и перегоняют LLVMIR в обычный бинарник.
Он парсится из текста в AST.
AST обрабатывается и оптимизируется в HIR
HIR обрабатывается и оптимизируется в MIR.
MIR делает проверки заимствования и оптимизацию и перегоняется в LLVMIR.
LLVMIR компилируется на конечной платформе.
Пробуем ручками
Ну что же, напоследок осталось написать простенькую программку, типа этого:
И начать её компилировать, только показывая все внутренности. Для начала есть замечательная опция компилятора, которая работает на любой версии:
Значит, запуская компиляцию следующим образом:
Мы получаем на выходе мириады различных форматов, включая сгенерированный ассемблеровский код, байткод и IR для LLVM, и даже челвоеко-читаемый MIR.
А если у вас есть nightly компилятор, то вы можете запустить
И полюбоваться вашим HIR, в то время как
Даст вам возможность посмотреть на то, как выглядит AST.
Напоследок
Ну что же, мы залезли в дебри компилятора. Теперь вы знаете, что происходит каждый раз когда вы запускаете билд на своей машине. Я показал вам rust. Но не бойтесь, ваш любимый язык, скорее всего, ничуть не менее сложен. Проще будет только компилировать ассемблер для 386 под досом. И не важно, если вы запускаете C#, Java, Javascript, Golang или haskell. Происходить будет многое, хотя и совсем по-разному.
Понятно? Ну и хорошо.