Создание кастомных расширений для компиляторов C++ — инструмент оптимизации кода, внедрения новых языковых функций и автоматизации задач. Многие разработчики недооценивают гибкость современных компиляторов и возможности их настройки. Расширения позволяют вмешиваться в процесс компиляции на разных этапах — от анализа кода до генерации машинных инструкций. Это даёт возможность настраивать компилятор под конкретные задачи, добавлять проверки или создавать специализированные оптимизации. Модификация существующих компиляторов имеет значительные преимущества перед разработкой новых. Это экономит ресурсы и обеспечивает совместимость с существующим кодом. Популярные компиляторы, такие как GCC и Clang, предоставляют API для создания расширений.
Применение расширений компилятора выходит за рамки оптимизации. Они используются для статического анализа, поиска уязвимостей, автоматического рефакторинга и создания предметно-ориентированных языков на базе C++.
Теоретическая база
Процесс компиляции начинается с лексического анализа (лексер), который преобразует исходный текст программы в поток токенов. Токены — это мельчайшие значимые единицы языка: ключевые слова, идентификаторы, литералы, операторы и разделители. Например, строка кода int x = 5; будет разбита на токены: int, x, =, 5, ;. После лексического анализа включается синтаксический анализатор (парсер), проверяющий правильность структуры программы согласно грамматике языка. Парсер группирует токены в синтаксические конструкции и строит древовидное представление программы — абстрактное синтаксическое дерево (AST).
AST — ключевой элемент для разработки расширений компилятора. Это структура данных, представляющая синтаксис программы в виде дерева, где каждый узел соответствует конструкции исходного кода. AST абстрагируется от конкретного синтаксиса, сохраняя семантическую структуру программы. Рассмотрим фрагмент:
| C++ | 1
2
3
| if (x > 0) {
return x * 2;
} |
|
| Code | 1
2
3
4
5
6
7
8
9
| Корневой узел: IfStatement
- Условие: BinaryOperator (">")
- Левый операнд: VariableReference ("x")
- Правый операнд: IntegerLiteral (0)
- Тело: CompoundStatement
- Оператор: ReturnStatement
- Выражение: BinaryOperator ("*")
- Левый операнд: VariableReference ("x")
- Правый операнд: IntegerLiteral (2) |
|
| C++ | 1
2
3
4
| define i32 @add(i32 %a, i32 %b) {
%sum = add i32 %a, %b
ret i32 %sum
} |
|
После создания IR происходит серия оптимизационных проходов. Здесь открывается широкое поле для создания расширений компилятора. Разработчики могут добавлять собственные оптимизационные проходы, нацеленные на конкретные шаблоны кода или архитектуры. Финальный этап компиляции — генерация машинного кода для целевой платформы. На этом этапе IR преобразуется в инструкции конкретного процессора. Некоторые расширения компилятора работают именно на этом уровне, адаптируя генерацию кода под специфические процессоры или ускорители.
Современные компиляторные фреймворки, такие как LLVM, предоставляют модульную архитектуру. Это значит, что создание расширения не требует модификации всего компилятора. Достаточно написать плагин, который будет взаимодействовать с существующими компонентами через хорошо документированные API. При разработке расширений компилятора важно понимать разницу между фронтендом и бэкендом. Фронтенд отвечает за обработку исходного кода на конкретном языке и создание AST. Бэкенд преобразует IR в машинный код для целевой платформы. Для C++ основными фронтендами являются Clang (для LLVM) и G++ (для GCC).
Ошибка компилятора fatal error C1091: ограничение компилятора: длина строки превышает 65535 байт
Компилируя программу вот такой командой:
cl /O2 /Oi /GL /EHsc /MD /Gy main.cpp
И компилятор... Разработка расширений и плагинов для FireFox
Где находятся доки (сабж) на сайте Mozilla?
Дайте ссыль.
Что еще почитать по теме
(книги,... Разработка расширений для игр
Недавно получил тестовое задание по Unity. Разработать базовую игру и ее расширение.
Базовая игра... Разработка расширений для VS Code
Всем привет.
Посоветуйте толковые материалы с примерами для разработки расширений для VS Code....
Лексический и синтаксический анализ как точки входа для расширений
Лексический и синтаксический анализаторы — первые компоненты компилятора, встречающие исходный код, и они предоставляют мощные возможности для создания расширений. Фактически, именно на этих этапах можно реализовать такие функции, как нестандартный синтаксис, кастомные директивы препроцессора или даже поддержку предметно-ориентированных языков (DSL) внутри C++ кода. Для модификации лексического анализатора обычно требуется добавление новых типов токенов или изменение правил токенизации. Например, если вы хотите добавить в C++ новый оператор, такой как оператор возведения в степень **, необходимо научить лексер распознавать эту последовательность символов как отдельный токен, а не как два последовательных оператора умножения.
| C++ | 1
2
| // Пример кода с нестандартным оператором
int power = 2 ** 3; // Должно интерпретироваться как 2^3 = 8 |
|
| C++ | 1
2
3
4
5
6
7
| class CustomPPCallbacks : public clang::PPCallbacks {
public:
void MacroExpands(const Token &MacroNameTok, const MacroDefinition &MD,
SourceRange Range, const MacroArgs *Args) override {
// Здесь можно модифицировать макросы при их развёртывании
}
}; |
|
| C++ | 1
2
| // Нестандартный синтаксис лямбда-выражения
fn(int x) -> x * 2; // Вместо стандартного [](int x) { return x * 2; } |
|
| C++ | 1
2
3
4
5
6
7
8
9
10
| class CustomSyntaxAction : public PluginASTAction {
protected:
std::unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI,
llvm::StringRef) override {
Preprocessor &PP = CI.getPreprocessor();
// Добавляем обработчик для препроцессора
PP.addPPCallbacks(std::make_unique<CustomPPCallbacks>());
return std::make_unique<CustomASTConsumer>();
}
}; |
|
Одним из интересных применений расширений на уровне лексического анализа является создание специализированных предупреждений и ошибок для конкретных команд разработки. Например, можно запретить использование определённых API или функций в критичных участках кода:
| C++ | 1
2
3
| void critical_function() {
malloc(1024); // Компилятор выдаст ошибку: "Запрещено использовать malloc в критичных функциях"
} |
|
| C++ | 1
2
3
4
5
| DiagnosticsEngine &DE = CI.getDiagnostics();
unsigned ID = DE.getCustomDiagID(
DiagnosticsEngine::Error,
"Запрещено использовать %0 в критичных функциях");
DE.Report(Loc, ID) << "malloc"; |
|
| C++ | 1
2
3
4
| class User {
private int age;
public prop int Age { get; set; } // Автоматически генерирует геттер и сеттер
}; |
|
| C++ | 1
2
| RewriteBuffer &RewriteBuf = Rewriter.getEditBuffer(SM.getMainFileID());
Rewriter.ReplaceText(SourceRange(StartLoc, EndLoc), NewText); |
|
| C++ | 1
2
3
4
| class [[serializable]] User { // Атрибут указывает компилятору сгенерировать методы сериализации
int id;
std::string name;
}; |
|
-dump-tokens и -ast-dump:
| Bash | 1
2
| clang++ -Xclang -dump-tokens file.cpp # Вывод токенов
clang++ -Xclang -ast-dump file.cpp # Вывод AST |
|
При внедрении нестандартного синтаксиса нужно заботиться о совместимости с существующими инструментами разработки. IDE, форматеры кода и другие утилиты могут не распознавать кастомные конструкции, что усложняет работу с кодом.
Семантический анализ и возможности его модификации
После лексического и синтаксического анализа следует этап семантического анализа. На этом этапе компилятор проверяет смысловую корректность программы: типы данных, область видимости переменных, перегрузку функций и другие аспекты, которые невозможно проверить только по синтаксису. Семантический анализ работает с уже построенным AST, но дополняет его информацией о типах, символах и другими метаданными. Это делает данный этап особенно ценным для создания расширений компилятора, которые фокусируются на проверке корректности кода и выявлении потенциальных ошибок.
Расширения на уровне семантического анализа могут решать различные задачи:
1. Статический анализ кода для выявления потенциальных проблем.
2. Проверка соблюдения специфических правил кодирования.
3. Автоматическое выведение типов или упрощение работы с типами.
4. Добавление метаинформации для кодогенерации.
В Clang расширения семантического анализатора обычно реализуются через AST Matchers и написание собственных проверок. AST Matchers — это декларативный механизм, позволяющий находить определённые конструкции в дереве AST:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
| auto matcher = functionDecl(hasName("memcpy"),
hasParameter(0, hasType(pointerType())))
.bind("memcpy_call");
class MemcpyCallHandler : public MatchFinder::MatchCallback {
public:
void run(const MatchFinder::MatchResult &Result) override {
const FunctionDecl *FD = Result.Nodes.getNodeAs<FunctionDecl>("memcpy_call");
// Проверка и анализ вызова memcpy
}
}; |
|
memcpy и передаёт их объекту-обработчику для дальнейшего анализа.
Одно из мощных применений расширений семантического анализа — проверка на потенциальные ошибки, связанные с управлением ресурсами. Например, можно создать проверку, которая выявляет потенциальные утечки памяти или неправильное использование мьютексов:
| C++ | 1
2
3
4
5
6
7
8
9
10
| std::mutex mtx;
void potential_deadlock() {
mtx.lock();
if (condition) {
// Компилятор выдаст предупреждение: "Возможен deadlock: функция может вернуть управление без разблокировки мьютекса"
return;
}
mtx.unlock();
} |
|
| C++ | 1
2
3
4
5
6
7
| auto mutexLockMatcher = callExpr(callee(methodDecl(hasName("lock"),
ofClass(hasName("mutex"))))).bind("lock");
auto returnAfterLockMatcher = returnStmt(hasAncestor(
compoundStmt(hasDescendant(mutexLockMatcher),
unless(hasDescendant(callExpr(
callee(methodDecl(hasName("unlock"))))))))); |
|
lock() без соответствующего unlock().
Модификация правил проверки типов — ещё одна мощная возможность семантического анализа. Например, можно запретить неявные преобразования между определёнными типами, которые технически допустимы, но могут приводить к ошибкам:
| C++ | 1
2
3
4
5
6
7
8
9
| class DistanceInMiles {};
class DistanceInKilometers {};
void requiresKilometers(DistanceInKilometers);
void foo() {
DistanceInMiles miles;
requiresKilometers(miles); // Компилятор: "Ошибка: неявное преобразование из Miles в Kilometers запрещено"
} |
|
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| bool VisitImplicitCastExpr(ImplicitCastExpr *E) {
QualType FromType = E->getSubExpr()->getType();
QualType ToType = E->getType();
if (FromType->isClassType() && ToType->isClassType()) {
if (isProhibitedConversion(FromType, ToType)) {
DiagnosticsEngine &DE = CI.getDiagnostics();
unsigned ID = DE.getCustomDiagID(
DiagnosticsEngine::Error,
"Неявное преобразование из %0 в %1 запрещено");
DE.Report(E->getExprLoc(), ID)
<< FromType.getAsString() << ToType.getAsString();
}
}
return true;
} |
|
| C++ | 1
2
3
4
5
| [[noexcept_attr]]
void critical_function() {
std::vector<int> v;
v.at(10); // Компилятор: "Ошибка: потенциальное исключение в функции с атрибутом noexcept_attr"
} |
|
| C++ | 1
2
3
4
5
| class IncompleteRule5 {
public:
IncompleteRule5(const IncompleteRule5&) = default;
// Компилятор: "Предупреждение: класс определяет копирующий конструктор, но не определяет оператор присваивания"
}; |
|
Реализация пользовательских семантических анализаторов также открывает возможности для создания более интеллектуальных систем документирования кода. Например, можно автоматически проверять соответствие комментариев функции её фактическому поведению:
| C++ | 1
2
3
4
5
6
7
8
| // Эта функция возвращает максимальное значение из массива
int findMax(int* arr, int size) {
int min = arr[0]; // Семантический анализатор обнаружит несоответствие
for (int i = 1; i < size; i++) {
if (arr[i] < min) min = arr[i];
}
return min; // Возвращается минимум, а не максимум
} |
|
| C++ | 1
2
3
4
5
| void getUserData(std::string user_input) {
std::string query = "SELECT * FROM users WHERE id = " + user_input;
// Предупреждение: неэкранированная строка в SQL-запросе
db.execute(query);
} |
|
| C++ | 1
2
3
4
5
6
7
| std::atomic<int> counter(0);
int non_atomic = 0;
void thread_func() {
counter++; // Безопасно
non_atomic++; // Предупреждение: неатомарная операция с разделяемыми данными
} |
|
| C++ | 1
2
3
4
5
6
7
| class Logger {
public:
[[log_calls]] // Этот атрибут инструктирует компилятор добавить логирование
void importantOperation() {
// код функции
}
}; |
|
Практический подход
Теоретическое понимание компиляторов — отличная основа, но для создания реальных расширений необходимо погрузиться в практику. Самыми удобными инструментами для разработки кастомных расширений C++ считаются компиляторы на базе LLVM, особенно Clang, благодаря их модульной архитектуре и хорошо документированному API.
Clang предоставляет несколько путей для создания расширений:
1. LibTooling — библиотека для создания автономных инструментов, работающих с исходным кодом C++. Этот подход идеален для инструментов статического анализа и автоматического рефакторинга.
2. Плагины компилятора — динамически загружаемые библиотеки, которые встраиваются в процесс компиляции. Плагины получают прямой доступ к внутренним структурам данных компилятора.
3. LibASTMatchers — удобный способ искать определённые узлы в AST с использованием декларативного API.
4. Clang Tidy — расширяемый фреймворк для диагностики и исправления типичных ошибок программирования.
Для нашего первого примера создадим простое расширение, которое предупреждает о функциях с избыточным количеством параметров. Начнём с создания плагина для Clang:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| #include "clang/Frontend/FrontendPluginRegistry.h"
#include "clang/AST/AST.h"
#include "clang/AST/ASTConsumer.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
using namespace clang;
using namespace clang::ast_matchers;
class TooManyParamsCheck : public MatchFinder::MatchCallback {
private:
CompilerInstance &CI;
unsigned MaxParams;
public:
TooManyParamsCheck(CompilerInstance &CI, unsigned MaxParams = 5)
: CI(CI), MaxParams(MaxParams) {}
void run(const MatchFinder::MatchResult &Result) override {
const FunctionDecl *Func = Result.Nodes.getNodeAs<FunctionDecl>("funcDecl");
if (!Func)
return;
if (Func->param_size() > MaxParams) {
DiagnosticsEngine &DE = CI.getDiagnostics();
unsigned DiagID = DE.getCustomDiagID(
DiagnosticsEngine::Warning,
"функция '%0' имеет %1 параметров (превышен лимит %2)");
DE.Report(Func->getLocation(), DiagID)
<< Func->getName() << Func->param_size() << MaxParams;
}
}
}; |
|
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| class TooManyParamsConsumer : public ASTConsumer {
private:
MatchFinder Matcher;
TooManyParamsCheck Checker;
public:
TooManyParamsConsumer(CompilerInstance &CI)
: Checker(CI) {
Matcher.addMatcher(
functionDecl().bind("funcDecl"),
&Checker);
}
void HandleTranslationUnit(ASTContext &Context) override {
Matcher.matchAST(Context);
}
};
class TooManyParamsAction : public PluginASTAction {
protected:
std::unique_ptr<ASTConsumer> CreateASTConsumer(
CompilerInstance &CI, llvm::StringRef) override {
return std::make_unique<TooManyParamsConsumer>(CI);
}
bool ParseArgs(const CompilerInstance &CI,
const std::vector<std::string> &Args) override {
return true;
}
};
static FrontendPluginRegistry::Add<TooManyParamsAction>
X("too-many-params", "Проверка на избыточное количество параметров"); |
|
| Bash | 1
2
3
4
5
| # Компиляция плагина
clang++ -fPIC -shared -o TooManyParams.so TooManyParams.cpp `llvm-config --cxxflags --ldflags --system-libs --libs all`
# Использование плагина
clang++ -Xclang -load -Xclang ./TooManyParams.so -Xclang -plugin -Xclang too-many-params test.cpp |
|
| C++ | 1
2
3
4
5
6
7
8
9
| // test.cpp
void tooComplexFunction(int a, int b, int c, int d, int e, int f, int g) {
// Реализация
}
int main() {
tooComplexFunction(1, 2, 3, 4, 5, 6, 7);
return 0;
} |
|
| C++ | 1
2
3
| test.cpp:1:6: warning: функция 'tooComplexFunction' имеет 7 параметров (превышен лимит 5)
void tooComplexFunction(int a, int b, int c, int d, int e, int f, int g) {
^ |
|
Помимо плагинов, Clang предоставляет фреймворк LibTooling для создания автономных инструментов. Этот подход часто предпочтительнее, так как позволяет запускать анализ независимо от процесса компиляции. Вот эквивалент нашего плагина с использованием LibTooling:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| // TooManyParamsTool.cpp
#include "clang/Frontend/FrontendActions.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
using namespace clang;
using namespace clang::ast_matchers;
using namespace clang::tooling;
// Опции командной строки
static llvm::cl::OptionCategory ToolCategory("too-many-params options");
class TooManyParamsFinder : public MatchFinder::MatchCallback {
public:
void run(const MatchFinder::MatchResult &Result) override {
const FunctionDecl *Func = Result.Nodes.getNodeAs<FunctionDecl>("funcDecl");
if (!Func)
return;
if (Func->param_size() > 5) {
auto &SM = *Result.SourceManager;
auto Loc = Func->getLocation();
llvm::errs() << SM.getFilename(Loc) << ":"
<< SM.getSpellingLineNumber(Loc) << ":"
<< SM.getSpellingColumnNumber(Loc) << ": warning: ";
llvm::errs() << "функция '" << Func->getName() << "' имеет "
<< Func->param_size() << " параметров (превышен лимит 5)\n";
}
}
};
int main(int argc, const char **argv) {
auto ExpectedParser = CommonOptionsParser::create(argc, argv, ToolCategory);
if (!ExpectedParser) {
llvm::errs() << ExpectedParser.takeError();
return 1;
}
CommonOptionsParser &OptionsParser = ExpectedParser.get();
ClangTool Tool(OptionsParser.getCompilations(),
OptionsParser.getSourcePathList());
TooManyParamsFinder Finder;
MatchFinder Matcher;
Matcher.addMatcher(functionDecl().bind("funcDecl"), &Finder);
return Tool.run(newFrontendActionFactory(&Matcher).get());
} |
|
Настройка среды разработки для работы с LLVM инфраструктурой
Прежде чем погрузиться в разработку расширений компилятора, необходимо настроить рабочую среду. LLVM и Clang имеют множество зависимостей, и правильная настройка среды разработки значительно упростит работу с ними.
Создание рабочего окружения начинается с установки необходимых компонентов. На Linux наиболее простой способ — воспользоваться пакетным менеджером. Для Ubuntu/Debian:
| Bash | 1
2
| sudo apt-get update
sudo apt-get install llvm-dev libclang-dev clang |
|
| Bash | 1
| sudo dnf install llvm-devel clang-devel |
|
После установки базовых компонентов необходимо установить CMake и Ninja для сборки проектов:
| Bash | 1
| sudo apt-get install cmake ninja-build # Для Debian/Ubuntu |
|
clang --version и llvm-config --version должен вывести информацию о версиях.
При разработке расширений компилятора часто требуются заголовочные файлы LLVM и Clang. Путь к ним можно узнать с помощью команды:
| Bash | 1
| llvm-config --includedir |
|
| Bash | 1
| export LLVM_INCLUDE=$(llvm-config --includedir) |
|
Когда базовая установка завершена, можно перейти к созданию шаблона проекта расширения. Структура типичного проекта для разработки плагина Clang:
| C++ | 1
2
3
4
5
6
7
8
| plugin-project/
├── CMakeLists.txt
├── include/
│ └── MyPlugin.h
├── src/
│ └── MyPlugin.cpp
└── test/
└── test_cases.cpp |
|
CMakeLists.txt настраивает сборку проекта и должен включать пути к библиотекам LLVM/Clang:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| cmake_minimum_required(VERSION 3.13)
project(MyClangPlugin)
find_package(LLVM REQUIRED CONFIG)
find_package(Clang REQUIRED CONFIG)
include_directories(${LLVM_INCLUDE_DIRS})
include_directories(${CLANG_INCLUDE_DIRS})
add_definitions(${LLVM_DEFINITIONS})
add_library(MyPlugin MODULE src/MyPlugin.cpp)
# Установка опций компилятора
target_compile_features(MyPlugin PRIVATE cxx_std_14) |
|
Для тестирования расширений компилятора нужно создать файл конфигурации lit. В корне проекта создайте файл lit.cfg.py:
| Python | 1
2
3
4
5
6
7
8
| import lit.formats
import os
config.name = "MyPluginTests"
config.test_format = lit.formats.ShTest(True)
config.suffixes = ['.cpp', '.test']
config.test_source_root = os.path.dirname(__file__)
config.test_exec_root = os.path.join(config.test_source_root, 'build/test') |
|
compile_commands.json, который содержит точные команды компиляции для каждого файла. Для его создания добавьте в CMakeLists.txt:
| C++ | 1
| set(CMAKE_EXPORT_COMPILE_COMMANDS ON) |
|
.vscode/settings.json:
| JSON | 1
2
3
4
5
6
7
8
| {
"C_Cpp.default.compileCommands": "${workspaceFolder}/build/compile_commands.json",
"cmake.buildDirectory": "${workspaceFolder}/build",
"cmake.configureSettings": {
"LLVM_DIR": "/usr/lib/llvm-12/lib/cmake/llvm",
"Clang_DIR": "/usr/lib/llvm-12/lib/cmake/clang"
}
} |
|
| Bash | 1
2
| export LLVM_DEBUG=1
export CLANG_PLUGIN_LOG=1 |
|
| Bash | 1
2
3
4
5
| git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build && cd build
cmake -G Ninja -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release ../llvm
ninja |
|
Для автоматизации процесса тестирования используйте CI-системы. Например, для GitHub Actions создайте файл .github/workflows/plugin-ci.yml:
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| name: Plugin CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: sudo apt-get install llvm-dev libclang-dev
- name: Configure
run: cmake -B build -G Ninja
- name: Build
run: ninja -C build
- name: Test
run: lit -v build/test |
|
Отладка расширений компилятора: инструменты и методики
Отладка расширений компилятора существенно отличается от стандартной отладки прикладного кода. Это связано с многоэтапной природой компиляции и особенностями взаимодействия расширения с внутренними структурами компилятора. Эффективная отладка требует знания специальных инструментов и подходов.
Самый простой, но мощный инструмент — флаги отладки компилятора. Для Clang можно использовать следующие опции:
| Bash | 1
2
3
| clang++ -Xclang -ast-dump test.cpp # Выводит всё AST
clang++ -Xclang -ast-dump=json -fsyntax-only test.cpp # AST в JSON формате
clang++ -Xclang -dump-tokens test.cpp # Выводит токены |
|
DEBUG и LLVM_DEBUG:
| C++ | 1
2
| #define DEBUG_TYPE "my-plugin"
LLVM_DEBUG(llvm::dbgs() << "Обработка функции: " << FD->getName() << "\n"); |
|
| Bash | 1
| LLVM_DEBUG=1 clang++ -Xclang -load -Xclang ./my-plugin.so test.cpp |
|
| Bash | 1
| lldb -- clang++ -Xclang -load -Xclang ./my-plugin.so test.cpp |
|
Для проверки результатов трансформаций кода полезно сравнивать промежуточные представления:
| Bash | 1
2
3
| clang++ -emit-llvm -S -o test.ll test.cpp # Получение LLVM IR
clang++ -Xclang -load -Xclang ./my-plugin.so -emit-llvm -S -o test_transformed.ll test.cpp
diff test.ll test_transformed.ll # Сравнение результатов |
|
Автоматизированное тестирование — неотъемлемая часть разработки расширений компилятора. Фреймворк LIT (LLVM Integrated Tester) позволяет создавать тесты, проверяющие как положительные, так и отрицательные сценарии:
| C++ | 1
2
3
| // RUN: %clang_cc1 -load %plugin_lib -plugin my-plugin %s 2>&1 | FileCheck %s
void foo(int a, int b, int c, int d, int e, int f);
// CHECK: warning: функция 'foo' имеет 6 параметров |
|
| C++ | 1
2
3
4
| RewriteBuffer &Buffer = Rewriter.getEditBuffer(SM.getMainFileID());
std::error_code EC;
llvm::raw_fd_ostream OS("output.cpp", EC);
OS << Buffer.str(); |
|
Создание матчеров для поиска паттернов в AST
При разработке расширений компилятора часто возникает необходимость находить определённые конструкции в коде: вызовы функций, использование определённых классов или потенциально небезопасные операции. Для решения этой задачи Clang предоставляет мощную систему AST-матчеров — инструментов для декларативного поиска паттернов в абстрактном синтаксическом дереве.
AST-матчеры напоминают язык запросов для кода C++. Они позволяют описать, какую именно конструкцию вы ищете, не заботясь о деталях обхода дерева. Библиотека ASTMatchers предоставляет набор примитивов для построения сложных запросов:
| C++ | 1
2
| // Поиск всех вызовов функции printf
auto matcher = callExpr(callee(functionDecl(hasName("printf")))); |
|
malloc без последующей проверки на NULL:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
| auto mallocCallMatcher =
callExpr(callee(functionDecl(hasName("malloc")))).bind("mallocCall");
auto uncheckedMallocMatcher =
ifStmt(hasCondition(anyOf(
binaryOperator(
hasOperatorName("=="),
hasLHS(expr(hasDescendant(declRefExpr(to(
varDecl(hasInitializer(ignoringParenImpCasts(
expr(hasDescendant(mallocCallMatcher)))))))),
hasRHS(integerLiteral(equals(0)))))),
unless(hasParent(ifStmt()))); |
|
bind(), который привязывает имя к найденному узлу. Позже это имя используется для получения конкретного узла:
| C++ | 1
2
3
4
5
6
| void run(const MatchFinder::MatchResult &Result) override {
const CallExpr *Call = Result.Nodes.getNodeAs<CallExpr>("mallocCall");
if (Call) {
// Обработка найденного вызова malloc
}
} |
|
| C++ | 1
2
3
| auto unusedVarMatcher = varDecl(
hasType(isInteger()),
unless(isReferenced())).bind("unusedVar"); |
|
hasType), предикаты (unless, anyOf, allOf), проверки иерархии (hasParent, hasDescendant), сопоставление с шаблонами (templateSpecializationDecl) и многое другое.
Для применения матчеров необходимо создать экземпляр MatchFinder и зарегистрировать свой обработчик:
| C++ | 1
2
3
4
5
| MatchFinder Finder;
YourCallback Callback;
Finder.addMatcher(yourMatcher, &Callback);
Finder.matchAST(Context); |
|
-ast-dump, которая показывает полное дерево для анализируемого кода.
Техники трансформации кода на уровне AST
После того как нужные паттерны в коде найдены с помощью матчеров, следующий логичный шаг — трансформация исходного кода. Clang предоставляет мощные инструменты, позволяющие модифицировать код на уровне AST и автоматически применять эти изменения к исходным файлам.
Основным инструментом для трансформации кода является класс Rewriter. Этот класс позволяет вносить изменения в исходный текст программы, сохраняя форматирование, комментарии и другие элементы стиля:
| C++ | 1
2
3
4
5
6
| Rewriter TheRewriter;
TheRewriter.setSourceMgr(Result.Context->getSourceManager(), Result.Context->getLangOpts());
// Замена вызова функции на другую
SourceRange Range = Call->getSourceRange();
TheRewriter.ReplaceText(Range, "secure_malloc(" + Arg->getSourceRange().getAsString() + ")"); |
|
RefactoringTool из библиотеки LibTooling. Он позволяет создавать инструменты рефакторинга, которые можно запускать из командной строки:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class RenameTransform : public ASTConsumer {
private:
Rewriter &Rewrite;
std::string OldName, NewName;
public:
RenameTransform(Rewriter &R, std::string Old, std::string New)
: Rewrite(R), OldName(Old), NewName(New) {}
void HandleTranslationUnit(ASTContext &Context) override {
// Находим и заменяем имя
auto Matcher = declRefExpr(to(namedDecl(hasName(OldName)))).bind("ref");
MatchFinder Finder;
MyCallback Callback(Rewrite, NewName);
Finder.addMatcher(Matcher, &Callback);
Finder.matchAST(Context);
}
}; |
|
1. Локальные замены. Простые замены текста, например, переименование переменной или функции.
2. Структурные изменения. Модификация структуры кода, например, изменение сигнатуры функции или преобразование цикла for в while.
3. Семантические трансформации. Изменения, которые учитывают семантику программы, например, автоматическое добавление проверок на ошибки.
При работе с трансформациями важно учитывать, что AST представляет уже типизированную и семантически проверенную структуру программы. Поэтому трансформации, меняющие семантику, требуют особого внимания — компилятор уже проверил исходную версию, но не проверяет результат трансформации.
Практический пример трансформации — автоматическое добавление проверок на NULL после вызовов malloc:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| void run(const MatchFinder::MatchResult &Result) override {
const CallExpr *Call = Result.Nodes.getNodeAs<CallExpr>("mallocCall");
if (!Call)
return;
// Находим оператор присваивания результата malloc переменной
const Stmt *Parent = Result.Context->getParents(*Call)[0];
const BinaryOperator *Assign = dyn_cast<BinaryOperator>(Parent);
if (!Assign || Assign->getOpcode() != BO_Assign)
return;
// Получаем имя переменной
const DeclRefExpr *Ref = dyn_cast<DeclRefExpr>(Assign->getLHS()->IgnoreParenImpCasts());
if (!Ref)
return;
// Добавляем проверку на NULL после присваивания
SourceLocation Loc = Assign->getEndLoc().getLocWithOffset(1);
std::string NullCheck = "
if (" + Ref->getNameInfo().getAsString() + " == NULL) {
fprintf(stderr, \"Memory allocation failed\\n\");
exit(1);
}
";
Rewriter.InsertText(Loc, NullCheck, true, true);
} |
|
| C++ | 1
2
3
4
5
6
7
8
9
| // Старый стиль
for (std::vector<int>::iterator it = vec.begin(); it != vec.end(); ++it) {
// Работа с *it
}
// Новый стиль (после трансформации)
for (auto & elem : vec) {
// Работа с elem
} |
|
for с соответствующей структурой и заменить их на новый синтаксис. При трансформации кода часто необходимо обрабатывать макросы, что представляет особую сложность. Макросы расширяются до того, как компилятор создаёт AST, поэтому информация о них может быть частично потеряна. Для работы с кодом, содержащим макросы, используются специальные методы:
| C++ | 1
2
| bool isInMacroExpansion = Result.SourceManager->isMacroBodyExpansion(Loc);
SourceLocation SpellingLoc = Result.SourceManager->getSpellingLoc(Loc); |
|
Rewriter автоматически сохраняет большинство элементов форматирования, но иногда требуется дополнительная обработка:
| C++ | 1
2
3
4
5
6
| // Преобразование с сохранением отступов
std::string GetIndent(SourceLocation Loc, SourceManager &SM) {
unsigned LineNo = SM.getSpellingLineNumber(Loc);
StringRef Line = GetLine(Loc, SM);
return Line.substr(0, Line.find_first_not_of(" \t"));
} |
|
1. Определение переменных, используемых в выделяемом фрагменте кода.
2. Определение переменных, модифицируемых в этом фрагменте.
3. Создание сигнатуры функции на основе этой информации.
4. Замена исходного кода вызовом новой функции.
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| void ExtractMethod(SourceRange Range,
const std::string &FunctionName,
const std::vector<VarDecl*> &InputVars,
const std::vector<VarDecl*> &OutputVars) {
// Генерация сигнатуры функции
std::string FuncSignature = "void " + FunctionName + "(";
// Добавление входных параметров
for (const auto *Var : InputVars) {
FuncSignature += Var->getType().getAsString() + " " +
Var->getName().str() + ", ";
}
// Добавление выходных параметров (по ссылке)
for (const auto *Var : OutputVars) {
FuncSignature += Var->getType().getAsString() + "& " +
Var->getName().str() + ", ";
}
// Удаление последней запятой
if (!InputVars.empty() || !OutputVars.empty())
FuncSignature.erase(FuncSignature.size() - 2);
FuncSignature += ")";
// Извлечение текста выделенного диапазона
std::string BodyText = Rewriter.getRewrittenText(Range);
// Создание тела функции
std::string FunctionDef = FuncSignature + " {\n" + BodyText + "\n}\n\n";
// Добавление определения функции перед текущей функцией
FunctionDecl *CurrentFunction =
Result.Nodes.getNodeAs<FunctionDecl>("currentFunction");
Rewriter.InsertText(CurrentFunction->getBeginLoc(), FunctionDef, true, true);
// Замена исходного кода вызовом функции
std::string FunctionCall = FunctionName + "(";
// Добавление аргументов
for (const auto *Var : InputVars)
FunctionCall += Var->getName().str() + ", ";
for (const auto *Var : OutputVars)
FunctionCall += Var->getName().str() + ", ";
// Удаление последней запятой
if (!InputVars.empty() || !OutputVars.empty())
FunctionCall.erase(FunctionCall.size() - 2);
FunctionCall += ");";
Rewriter.ReplaceText(Range, FunctionCall);
} |
|
ClangTool с указанием списка файлов:
| C++ | 1
2
3
4
5
6
| std::vector<std::string> SourcePaths;
SourcePaths.push_back("file1.cpp");
SourcePaths.push_back("file2.cpp");
ClangTool Tool(OptionsParser.getCompilations(), SourcePaths);
Tool.run(newFrontendActionFactory<MyAction>().get()); |
|
Прикладные сценарии использования
Оптимизация кода для специфических аппаратных архитектур — один из наиболее распространённых сценариев использования кастомных расширений. Вместо создания общих оптимизаций для всех платформ, разработчики высокопроизводительных систем часто создают специализированные оптимизации, учитывающие особенности конкретных процессоров. Например, генерация кода, использующего специфические SIMD-инструкции или оптимальные для данной архитектуры шаблоны доступа к памяти.
Проверка соблюдения корпоративных стандартов кодирования — ещё одно важное применение. Многие организации имеют собственные правила и ограничения, выходящие за рамки возможностей стандартных линтеров. Кастомные расширения позволяют проверять такие правила на этапе компиляции:
| C++ | 1
2
3
4
| void sensitive_function() {
std::string password = "hardcoded"; // Ошибка: обнаружена захардкоженная строка в секретной функции
log_operation("User logged in"); // Предупреждение: неконтролируемое логирование в секретной функции
} |
|
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
| // Исходный код
int calculate_value(int input) {
return input * factor;
}
// После автоматической трансформации
int calculate_value(int input) {
TRACE_FUNCTION_ENTRY("calculate_value", input);
auto result = input * factor;
TRACE_FUNCTION_EXIT("calculate_value", result);
return result;
} |
|
Кастомные оптимизаторы для высоконагруженных вычислений
В области высокопроизводительных вычислений стандартные оптимизации компиляторов часто оказываются недостаточными. Высоконагруженные системы — от научных расчётов до финансового моделирования и машинного обучения — требуют максимального использования возможностей оборудования. Кастомные оптимизаторы позволяют учитывать специфические паттерны вычислений и архитектурные особенности целевых систем. Разработка таких оптимизаторов начинается с анализа "горячих" участков кода — тех, которые потребляют большую часть вычислительных ресурсов.
Одна из распространённых оптимизаций — автоматическая векторизация для конкретных SIMD-инструкций. В отличие от стандартных векторизаторов, кастомные расширения могут учитывать особенности конкретных алгоритмов:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| // До оптимизации - стандартный цикл
for (int i = 0; i < size; i++) {
result[i] = a[i] * b[i] + c[i];
}
// После специализированной векторизации для AVX-512
void compute_optimized(float* result, float* a, float* b, float* c, int size) {
// Автоматически сгенерированный оптимизатором код
for (int i = 0; i < size; i += 16) {
__m512 va = _mm512_loadu_ps(&a[i]);
__m512 vb = _mm512_loadu_ps(&b[i]);
__m512 vc = _mm512_loadu_ps(&c[i]);
__m512 vr = _mm512_fmadd_ps(va, vb, vc);
_mm512_storeu_ps(&result[i], vr);
}
// Обработка хвоста массива
} |
|
Другой важный класс оптимизаций — специализированное развёртывание циклов (loop unrolling) с учётом специфики памяти конкретного процессора. Компилятор может не знать оптимального коэффициента развёртывания для вашей архитектуры, но кастомный оптимизатор может:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| // Исходный код
for (int i = 0; i < n; i++) {
sum += array[i];
}
// Трансформация с учётом размера кеш-линии и пропускной способности памяти
int i = 0;
for (; i < n - 7; i += 8) {
sum1 += array[i];
sum2 += array[i+1];
sum3 += array[i+2];
sum4 += array[i+3];
sum5 += array[i+4];
sum6 += array[i+5];
sum7 += array[i+6];
sum8 += array[i+7];
}
for (; i < n; i++) {
sum += array[i];
}
sum = sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum; |
|
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
| // Исходная структура данных (AoS - Array of Structures)
struct Particle {
float x, y, z;
float vx, vy, vz;
};
std::vector<Particle> particles;
// Оптимизированная структура (SoA - Structure of Arrays)
struct ParticleSystem {
std::vector<float> x, y, z;
std::vector<float> vx, vy, vz;
}; |
|
Оптимизация функций с учётом специализированных знаний о предметной области тоже находка для высокопроизводительных систем. Например, если известно, что матрица всегда имеет определённую структуру (разреженная, треугольная, диагональная), можно автоматически заменять общие алгоритмы специализированными:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
| // Обобщённое умножение матрицы на вектор
for (int i = 0; i < n; i++) {
for (int j = 0; j < n; j++) {
result[i] += matrix[i][j] * vector[j];
}
}
// Оптимизированная версия для разреженных матриц
for (int i = 0; i < n; i++) {
for (int idx = row_ptr[i]; idx < row_ptr[i+1]; idx++) {
result[i] += values[idx] * vector[col_idx[idx]];
}
} |
|
Интеграция с системами непрерывной интеграции (CI/CD)
Эффективное применение кастомных расширений компилятора требует их встраивания в автоматизированные процессы сборки и тестирования. Интеграция с CI/CD-системами позволяет применять расширения ко всей кодовой базе проекта при каждом изменении, обеспечивая раннее обнаружение проблем.
Для включения расширения в GitHub Actions достаточно модифицировать рабочий процесс сборки:
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
| jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: sudo apt-get install -y clang llvm-dev
- name: Build plugin
run: cmake -B build && cmake --build build
- name: Build with plugin
run: |
clang++ -Xclang -load -Xclang ./build/lib/MyPlugin.so \
-Xclang -plugin -Xclang my-plugin-name *.cpp |
|
| Code | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| pipeline {
agent any
stages {
stage('Build plugin') {
steps {
sh 'cmake -B build && cmake --build build'
}
}
stage('Analyze code') {
steps {
sh '''
clang-tidy -checks=* \
--load=$WORKSPACE/build/lib/MyPlugin.so *.cpp
'''
}
}
}
} |
|
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| stages:
- build
- analyze
build_plugin:
stage: build
script:
- cmake -B build && cmake --build build
artifacts:
paths:
- build/lib/MyPlugin.so
static_analysis:
stage: analyze
script:
- clang++ -Xclang -load -Xclang ./build/lib/MyPlugin.so -c *.cpp |
|
Реализация предметно-ориентированных языковых расширений (DSL)
Предметно-ориентированные языки (DSL) — специализированные языки программирования, созданные для решения задач в конкретной предметной области. Расширения компилятора C++ открывают уникальную возможность внедрять DSL непосредственно в код C++, сохраняя при этом всю мощь базового языка. Реализация DSL через расширения компилятора обычно идёт одним из двух путей: созданием синтаксических расширений или встраиванием интерпретируемого DSL в строковые литералы. Первый подход более интегрирован с языком, но требует серьёзных модификаций компилятора:
| C++ | 1
2
3
4
| // Расширение синтаксиса C++ для матричных операций
matrix<3,3> A;
matrix<3,1> b;
auto x = solve A * x = b; // Нестандартный синтаксис для решения уравнения |
|
| C++ | 1
2
3
4
5
6
7
8
9
| class MatrixDSLAction : public PluginASTAction {
protected:
std::unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI,
llvm::StringRef) override {
Preprocessor &PP = CI.getPreprocessor();
PP.AddPPCallbacks(std::make_unique<MatrixDSLPPCallback>(PP));
return std::make_unique<MatrixDSLConsumer>(CI);
}
}; |
|
| C++ | 1
2
3
4
5
6
| // DSL для регулярных выражений через пользовательские литералы
auto pattern = R"(([a-z]+)@([a-z]+)\.com)"_regex;
std::string email = "user@example.com";
if (email matches pattern) { // 'matches' — перегруженный оператор
// Обработка совпадения
} |
|
| C++ | 1
2
3
4
5
6
7
8
9
| #pragma hardware_config
device serial {
baud_rate: 9600,
data_bits: 8,
parity: none,
stop_bits: 1
}
// Транслируется препроцессором в стандартный C++ |
|
Ограничения и альтернативные подходы
Несмотря на мощь и гибкость, кастомные расширения компилятора имеют свои ограничения. Первый серьёзный барьер — высокий порог входа. Разработка расширений требует глубокого понимания внутренней архитектуры компилятора, что делает её недоступной для многих программистов. Нестабильность API компиляторов представляет ещё одну проблему. Внутренние интерфейсы LLVM и Clang регулярно меняются между версиями, что может привести к неработоспособности расширений после обновления компилятора. Это особенно критично для долгосрочных проектов. Производительность также становится узким местом. Сложные расширения могут существенно замедлить процесс компиляции, что недопустимо для больших проектов, где время сборки итак измеряется часами.
Некоторые задачи, решаемые через расширения, имеют альтернативные подходы:
| C++ | 1
2
3
| // Вместо кастомного расширения для проверки стиля
// можно использовать аннотации и существующие инструменты
[[clang::warn_unused_result]] int critical_function(); |
|
| Bash | 1
2
| # Создание и использование проверки clang-tidy проще, чем разработка плагина
run-clang-tidy -checks='-*,my-custom-check' . |
|
Совместимость расширений с различными версиями компиляторов
Поддержка совместимости расширений с разными версиями компиляторов — одна из наиболее сложных задач при их разработке. API компиляторов, особенно Clang и LLVM, быстро эволюционируют, а внутренние интерфейсы часто меняются между минорными версиями. Расширение, работающее с Clang 10, может полностью отказаться функционировать в Clang 11 без соответствующих модификаций.
Для минимизации проблем совместимости применяются различные техники. Прежде всего — использование абстрактных адаптеров, изолирующих код расширения от конкретных API компилятора:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
| class CompilerVersionAdapter {
public:
virtual ~CompilerVersionAdapter() = default;
virtual void registerMatcher(MatchFinder &Finder) = 0;
static std::unique_ptr<CompilerVersionAdapter> create();
};
// Реализации для разных версий
class Clang10Adapter : public CompilerVersionAdapter {
void registerMatcher(MatchFinder &Finder) override {
// Специфичная для Clang 10 реализация
}
}; |
|
| YAML | 1
2
3
| # Пример конфигурации для CI
matrix:
clang_version: ["10.0", "11.0", "12.0", "13.0"] |
|
Производительность кастомных расширений и методы её измерения
Для измерения производительности расширений используются специализированные методики. Трассировка времени — базовый метод, показывающий, сколько времени занимает каждый этап работы расширения:
| C++ | 1
2
3
4
5
| auto start = std::chrono::high_resolution_clock::now();
// Операция расширения
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
llvm::errs() << "Время выполнения: " << duration.count() << " мс\n"; |
|
| C++ | 1
2
| #include "llvm/Support/Allocator.h"
llvm::BumpPtrAllocator Allocator; // Эффективное управление памятью |
|
| Bash | 1
2
3
4
5
| # Компиляция без расширения (база)
time clang++ -O2 -c test.cpp
# Компиляция с расширением
time clang++ -O2 -Xclang -load -Xclang ./MyPlugin.so -c test.cpp |
|
Кастомные поля для кастомных типов постов
Всем доброго времени суток. Мне необходимо добавить свой тип записей на wordpress. Т.е. вот есть... Установка кастомных клавиш для смены раскладки клавиатуры
Как установить свои клавиши для смены раскладки клавиатуры???
Конкретно мне удобнее сменять... Snmpd.conf: Отправка трапов для кастомных OID
Доброго времени суток!
Пытаюсь настроить snmpd на отправку трапов для кастомных OID.
В конфиге... Мини-браслет для получения кастомных событий с сервера
Ох сразу простите меня. За всё. И может я ещё и не в тот раздел залез.
Господа. Я прошу совета,... Как настроить иерархическую структуру для произвольных (кастомных) записей
Добрый день! Подскажите, пожалуйста, возможно ли на Wordpress настроить иерархическую структуру... разработка расширений под FF
есть тут знающие люди, с чего начать, где информацию брать? Разработка расширений программы (Плагины)
Задача такова, написать основную программу допустим по редактированию значений и отдельные плагины... Разработка сценария,перемещение нужных файлов-расширений в новый каталог
Задание у меня было такое.
На заданном логическом диске переместить все файлы с заданными... Вопрос о создании кастомных progressbar'ах
Собственно вопросы:
1) Возможно-ли создать очень "крутые"(например, кривые формы, ползёт хомяк и... Отображение кастомных виджетов в ListView
Здравствуйте! Недавно столкнулся со следующей задачей - есть полностью кастомный виджет,... Проблема отображения DataGrid при добавлении в него кастомных колонок от DataGridBoundColumn
Всем доброго дня! Неделю уже потратил на поиски и пробы, но без результата!
В общем создаю... Оптимизация кастомных мешей
Вот такой вопрос. Написал свой воксельный редактор и сверх того пишу игру (собсна редактор написан...
|
