на каком языке пишут плагины rust
Rust на примерах. Часть 1
Этот цикл статей является вольным переводом книги «Rust by Example», которую пишет Хорхе Апарисио на Github.
На момент написания этого топика автор книги создал 49 глав, в первой части будет перевод первых пяти. Убедитесь, что Rust установлен и под рукой имеется документация.
Содержание
1. Привет, мир!
Это код традиционной программы «Hello World»:
println! это макрос (мы рассмотрим их позже), который печатает текст в консоль.
Программа может быть сгенерирована с помощью компилятора Rust rustc:
rustc создаст бинарный файл «hello», который можно запустить:
2. Форматированный вывод
Макрос println! не только выводит в консоль, а также способен форматировать текст и сериализованные значения. Корректность проверяется во время компиляции.
Дополнительная информация о форматировании здесь: std::fmt
3. Литералы и операторы
Также целые числа можно выразить через шестнадцатеричное, восьмеричное или двоичное обозначение, используя один из префиксов: 0x, 0o или 0b.
В числовые литералы можно вставлять подчёркивания для читабельности, например, 1_000 такой же, как и 1000, а 0.000_001 такой же, как и 0.000001.
Доступные операторы и их приоритет похож на C-подобных языках.
4. Переменные
Значения (как и литералы) могут быть связаны с переменными, используя обозначение let.
4.1 Изменяемость
По умолчанию переменные нельзя изменять, но это можно исправить, добавив модификатор mut.
Компилятор будет выводить сообщения об ошибке изменчивости.
4.2 Области и видимость
Переменные имеют локальную область, и имеют видимость в блоке (блок представляет собой набор операторов, заключённых в фигурные скобки <>). Кроме того, допускается скрытие переменной.
4.3 Предварительное объявление
Можно сперва объявлять переменные, а инициализировать их позже. Но эта форма редко используется, так как это может привести к использованию неинициализированных переменных.
Компилятор запрещает использование неинициализированных переменных, так как это привело бы к непредсказуемым последствиям.
5. Типы
Rust обеспечивает безопасность с помощью статической проверки типов. Тип переменной может быть явно указан при её объявлении. Тем не менее, в большинстве случаев, компилятор сможет определить тип переменной из контекста, если это очевидно.
5.1 Приведение типов
Rust не предоставляет неявного преобразования типов (coercion) между примитивами, но, явное приведение типов (casting) может быть достигнуто с помощью ключевого слова as.
5.2 Литералы
Тип литералов без суффикса будет зависеть от того, как они используются. Если никаких ограничений не существует, то компилятор выдаст сообщение об ошибке.
5.3 Логический вывод
Логический вывод типов довольно умён. Тип добавляемой переменной используется как определитель типа для второй переменной. Вот продвинутый пример:
Отсутствует необходимость в аннотации типа переменной, компилятор счастлив как и программист!
5.4 Псевдонимы (алиасы)
Заключение
Присоединяйтесь к google-группе: Rust по-русски для получения дополнительной информации по этому языку.
Можно помочь с переводом на Github: github.com/eg0r/rust-by-example
Все замечания, ошибки или неточности отправляйте мне в почту.
Чем Rust отличается от «плюсов»: откровение ветерана С++
Rust часто называют преемником C++. Дмитрий Свиридкин рассказал на суровом программистском языке, так ли хорош любимчик пользователей Stack Overflow.
Программист. Разрабатывает на C++ и Rust решения для платформы компьютерного зрения в Arrival. Автор сборника материалов по C++.
Я решил попробовать Rust, потому что устал отлавливать на код-ревью (и не только) одни и те же ошибки в «плюсах». Обязательно кто-нибудь объявит статик-лямбду и захватит в неё по ссылке нестатический временный объект. А когда код с такими ошибками коммитят, он проходит тесты, предполагающие однократный запуск. Программа попадает в продакшен, где запускается пару раз и падает. На поиск и отладку багов уходит много сил и времени.
В Rust нет бардака с библиотеками
У С++ всегда было две проблемы: недостаточная квалификация разработчиков и отсутствие нормальных пакетных менеджеров.
Раньше приходилось гуглить, копировать и компилировать исходники библиотек — та ещё головная боль. Бывало, найдёшь исходники, а компилятор не подходит, потому что он слишком старый, хедеры протухшие или версии зависимостей не совпадают. Тогда вместо готового решения придумывали своё — и это своё всегда заканчивалось кучей багов.
Например, я видел реализации std::optional, которые не вызывают деструктор, даже если тип нетривиально деструктурируемый. Тогда как стандартная реализация — это куча boilerplate-кода, который даже командой из трёх-четырёх человек невозможно отладить.
Получается полный бардак. Часть кода покрывают тестами, она кое-как работает, а когда начинаешь детально тестировать — тут дедлок, там use-after-free и так далее. В Rust эти заботы можно частично переложить на плечи компилятора, но с ним иногда приходится бороться: богатая система типов требует более педантичной работы.
Чтобы писать на Rust, мне не пришлось менять IDE. Просто подключил к VS Code code-assistant rust-analyzer (это что-то вроде майкрософтовского IntelliSense). На прошлой работе писали в CLion от JetBrains. У неё есть неплохой плагин для Rust, но при рефакторинге он может наделать делов и оказать медвежью услугу. Так что IDE от JetBrains научили меня не доверять авторефакторингу — обязательно что-нибудь да сломается. Поэтому стараюсь аккуратно рефакторить сам.
Система типов в Rust защищает от ошибок
Бизнес-логика — именно то, что нужно писать на Rust, потому что с ним тяжело ошибиться. Ещё на прошлой работе мы запилили плагин — в качестве proof of concept того, что на Rust вообще можно создавать плагины к большому SDK. Логика была примитивная: принять список слов и проверить, совпадает ли с ним input.
Почему такой простой плагин? Потому что больше никто в команде не знал Rust. Язык молодой, и пока на нём мало кто пишет. Создавать проекты, которые может поддерживать только один разработчик, невыгодно. Проще найти «плюсовиков», поэтому C++ никуда не исчезнет.
На новой работе я перевожу часть проекта с «плюсов» на Rust. Язык подкупил меня мощной системой типов, которая позволяет выразить зависимости между временами жизни объектов. В языках с ещё более мощными системами типов, например с зависимыми типами, можно проверять статически рантаймовые ограничения. Например, запретить функции принимать пустые строки — компилятор проверит.
Однако у таких мощных языков есть общая проблема: вы замучаетесь доказывать компилятору, что код работает правильно и ничего в нём не нужно исправлять. К счастью, Rust не совсем такой, это золотая середина: с одной стороны, его система типов достаточно строгая, чтобы защитить вас от распространённых ошибок. С другой — не настолько строгая, чтобы приходилось мучиться с ней лишнего.
Программы на Rust без стороннего кода сравнимы по скорости с «плюсовыми»
На прошлой работе я переписывал большой графовый алгоритм — без unsafe-кода, с контейнерами из стандартной библиотеки.
По производительности программа была всего на 10% медленнее «плюсовой». При этом обошлись без стороннего кода. Считаю, что результат хороший. Под C++ пришлось три месяца искать hashmap и перебирать варианты: в одной выравнивание как-то хитро сконфигурировано и приводит к segfault, в другом exception вылетает, если хеш плохой, третий вообще уже четыре года не поддерживается.
Что же касается бенчмарков, то всегда можно подобрать тест, где выиграет нужный язык — хоть С++, хоть Rust. Достаточно знать тонкости работы с памятью в конкретном языке. Я, например, могу написать пример кода на Rust без лишних аллокаций, а в «плюсах» у аналогичной программы они будут, потому что организовать там safe по-другому нельзя. В общем, обсуждать производительность нужно на конкретном примере.
Code-assistant rust-analyzer отлично работает с шаблонами
В последнее время я оборачиваю небезопасные библиотеки языка С, чтобы подцепиться к каноническому Rust API. Если бы сразу начал писать на «плюсах», уже давно бы закончил и общался с железом, к которому эта библиотека поставляется. А так как пишу на Rust, то пришлось целую неделю аккуратно оборачивать код в канонические Rust-структуры. Столкнулся с тонкостями системы типов: вариантностью ссылок, контравариантностью типов. Если не обращать на них внимания, то safe-обёртка над C API будет некорректной.
Оборачивать низкоуровневый unsafe-код в safe на Rust довольно долго, но оно того стоит. «Плюсовой» IntelliSense вряд ли сравнится с мощным rust-analyzer и справится далеко не со всем кодом, особенно с шаблонами.
Возможно, с появлением стандарта С++20 появятся хинты и IntelliSense научится подсказывать внутри шаблонного кода, если в параметрах указать концепт. Думаю, раньше всех эту фичу внедрит в свои IDE JetBrains — если уже не начала втихаря над ней работать. Шаблоны без концептов в «плюсах» всегда работали плохо: стоит поставить неподходящий аргумент — и компилятор выдаёт огромные сообщения об ошибках. Пока у анализаторов Rust гораздо больше возможностей, да и писать шаблонный однотипный код на нём получается гораздо быстрее.
У Rust настоящая zero-cost abstraction
Помимо Rust, я присматривался и к другим языкам. Три года назад, когда впервые сменил работу, думал погрузиться в светлый мир JVM и написать что-нибудь на Kotlin. Но языки вроде Scala, Java и Kotlin можно применять далеко не везде. Виртуальные машины создают дополнительную нагрузку и для встраиваемого ПО в микрокомпьютерах не подходят. В таких системах пишут на чистом С, С++ или совсем страшных штуках вроде MISRA C.
У Rust, скомпилированного в native, нет дополнительного рантайма. RAII, деструкторы, конструкторы как в «плюсах». Только у Rust линейные типы и zero-cost с ними настоящий, а у C++ — нетривиальный деструктор у типа, и хоть убейтесь, но не получится передать его значение через регистры.
Ещё есть Zig — он очень похож на Rust. Там, например, тоже есть проверка lifetime, но организована она иначе, и то, как это сделано в Rust, мне нравится больше. Других языков с проверкой lifetime я не знаю, а в языках со сборщиками мусора она не нужна: если есть ссылка на объект, значит, он точно живой.
В Go механизм похожий, но там есть сборщик мусора. Мне предлагали перейти на него четыре года назад. Я попробовал, и синтаксис меня рассмешил. Стоит автоформатеру неправильно перенести строки, и программа не скомпилируется. А всё из-за неявной расстановки точек с запятой.
С похожей проблемой я сталкивался, когда мы в первый раз подключали сторонний форматер для «плюсов» — кажется, это был Uncrustify. Он убрал лишние фигурные скобки, и размер критических секций у меня резко вырос. Да уж, отличный форматер — поменял поведение программы. Мог бы просто весь код снести.
В Rust более лаконичный синтаксис, но к нему нужно привыкнуть
Вообще, синтаксис Rust меня вначале сильно раздражал, но я уже почти смирился с ним.
Раздражает символ ; в конце expression, который меняет возвращаемый тип на аналог сишного void. Поставил точку с запятой — программа перестаёт компилироваться. А компилятор молотит type-чекером, который занимает целое ядро, чтобы rust-analyzer и IDE написали красным: «Смотри, у тебя тут типы не сошлись».
Хорошо хоть в экосистеме Rust пофиксили много ошибок и в поставке уже есть официальный форматер, который всё делает правильно. Конечно, тоже есть проблемы. Например, если вы хотите сделать что-то серьёзное с пакетными менеджерами, например сложить собранные артефакты в каталог, то придётся вручную писать поверх скрипты, например на Bash. Штатными средствами это сделать либо нельзя, либо они unstable.
В целом я свыкся с упоротым синтаксисом и краткими ключевыми словами, но всё равно считаю, что они должны состоять хотя бы из трёх символов. Я люблю называть свои переменные fn, а мне его предлагают в качестве ключевого слова. С другой стороны, минималистичный синтаксис — это хорошо.
Лямбды можно писать кратко и без ключевого слова return — это экономит кучу времени. Зато когда после этого переключаешься на С++, то всё время забываешь писать return и, указав тип возврата, получаешь функции с неопределённым поведением. В С++ синтаксис лямбд вообще напоминает синтаксис обычных функций, только trailing return type сделали — ну, и на том спасибо, что уж там. А скобки и return нужно писать обязательно, иначе будете ждать от функции int, а она ничего не вернёт.
При этом Rust не панацея
Тех, кто только планирует погрузиться в Rust, предупреждаю: это не панацея от всех болячек C++. Он защищает вас от гонки данных через проверку borrow checker, но пропускает дедлоки. Защищает от use-after-free, но только в safe-подмножестве. Если же работаете с unsafe — у вас, по сути, будет тот же С++, только с более продвинутой стандартной библиотекой.
Хотя и здесь не всё так однозначно. Многие важные фичи, например для разработки драйверов или встроенного ПО, остаются нестабильными, а значит, писать на Rust серьёзные проекты пока рискованно. По этой причине от Rust часто отказываются в пользу C++, где всё давно stable и unsafe.
обложка: Polina Vari для Skillbox Media
Разработка игр на Rust. Обзор экосистемы
Здравствуйте! Я занимаюсь разработкой игры на Rust и хочу рассказать об этом.
Моя первая статья будет полезна тем, кто хочет начать делать игру на Rust, но не уверен, какие из пакетов (крейтов) стоит использовать и что вообще происходит в экосистеме Rust для игрового разработчика.
Небольшое отступление — зачем всё это? Есть же готовый X?
Под впечатлением вот этого выступления, я начал писать свой игровой движок на Haskell. Далеко дело не зашло, но я написал рендер моделек, простое освещение, немного сети.
Haskell дал возможность вынести контракты из проверок в рантайме на уровень системы типов. Ну и остальные вещи, о которых рассказывает Кармак — быть уверенным, что функция делает именно то, о чём декларирует в своём типе. Быть чуть ближе к настоящей формальной верификации нашего игрового кода — то есть, в теории, иметь гарантию корректной работы вообще без тестов.
Но, с Haskell было несколько проблем — для вывода 3д в реальном времени он достаточно медлителен. Не было сообщества занимающегося на нём играми. Не хватало нужных для игр библиотек.
С Rust же всё пошло куда веселее.
На мой взгляд, Rust сочетает все свойства, нужные игровым разработчикам, в очень правильном соотношении:
мощная, но при этом простая система типов;
абстракции бесплатны по перфомансу — не надо платить за те абстракции, которые не используешь в явном виде;
И при этом на нём очень просто писать код, язык маленький и простой.
Вернусь к экосистеме:
Работа с окнами:
Glutin — раст-альтернатива GLFW, используется в Servo, активно развивается. Создаёт окна на win/osx/linux/android. На ios еще не работает, кто-то хотел сделать, но с 2015 об этом желающем не слышно.
И есть биндинги к не-растовым библиотекам: glfw-rs rust-sdl2 rust-sfml (сайт). Все три живы и поддерживаются.
Графические API:
Есть возможность использовать напрямую OpenGL/DirectX/Vulkan, к тому же уже созданы растоспецифичные графические библиотеки.
Glium — безопасная обёртка над OpenGL, по факту — в основном над OpenGL 3, хорошо поддерживаются OpenGL
Погружаемся в логово ржавчины. Как работает компилятор 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. Происходить будет многое, хотя и совсем по-разному.
Понятно? Ну и хорошо.