Как мы разрабатывали версию PVS-Studio для Embarcadero RAD Studio

25 Апр 2013

Автор: Павел Еремеев

Думаю, подавляющему большинству читателей данного блога известно, что PVS-Studio — статический анализатор исходного кода на C/C++ . Однако, работая с результатами анализа из своей любимой IDE, думаю, что не многие задумываются над тем, что же на самом деле представляет собой анализатор кода. А ведь анализатор — это простое command-line приложение, требующее для своей работы громоздких и запутанных cfg файлов и длинной командной строки для запуска. Причём анализатор может быть запущен для проверки только одного файла одновременно, так что для проверки всех файлов приходится запускать его отдельно, на каждый файл, при этом результаты анализа будут выданы в виде обычного plain-text лога. Но подобные аспекты использования анализатора, конечно же, скрыты от конечного пользователя с помощью модуля-расширения для среды разработки. Именно этот модуль, взаимодействуя напрямую с проектом, загруженным в IDE, собирает все необходимые параметры, генерирует командные строки и осуществляет проверку всех требуемых исходных файлов, причём производит это распараллелено, используя все доступные ядра у многопроцессорной системы. И делает он всё это по одному простому клику по команде "проверить проект".

Поддержка C++ Builder была прекращена в PVS-Studio после версии 5.20. По всем возникшим вопросам вы можете обратиться в нашу поддержку.

На самом деле анализатор, конечно, не предназначен для прямого использования разработчиком, в чём он очень схож с другими программистскими и сборочными инструментами, такими как компиляторы, линковщики, отладчики и т.п. Но, использование анализатора PVS-Studio, конечно же, не ограничивается IDE плагином для сред разработки от Microsoft. Как и любой command-line инструмент, он может быть напрямую встроен в сборочную систему проекта, например MSBuild или make. Конечно, данная процедура требует определённого понимания устройства и принципов работы, прежде всего, рассматриваемой сборочной системы, а также и самого command-line анализатора.

Мы всегда старались облегчить подобный сценарий использования для наших клиентов. Для этого в анализатор была добавлена поддержка различных популярных препроцессоров (например, gcc и clang, ведь анализатор должен уметь, в любом случае, разбирать код, специфичный для используемых ими C++ диалектов), была обеспечена совместимость работы с популярными системами непрерывной интеграции. Недавно мы даже выпустили отдельный плагин для сборочной системы MSBuild (но не нужно путать его с IDE плагином!), который позволит встроить статический анализ в эту систему путём простого добавления в сборочный сценарий всего пары строк.

Тем не менее, такой способ проверки кода всё равно значительно уступает варианту с прямой интеграцией в IDE через плагин. Ведь помимо требования модификации сборочных сценариев, необходимо ведь ещё как-то и работать с полученными результатами анализа. Это удобнее всего делать как раз из плагина для среды разработки, обеспечивающего как наглядное представление результатов, так и возможность навигации по коду, содержащему выявленные анализатором дефекты, с использованием редактора кода самой IDE. И это не говоря уже о таких незаменимых вещах, предоставляемых встроенным IDE редактором, как подсветка синтаксиса и навигация по определениям макросов и типов. Безусловно, ещё встречаются разработчики, которые пишут программы в простом текстовом редакторе, собирают их напрямую из командной строки, а затем вручную подключают к запущенному процессу отладчик. И хотя такой подход конечно более гибок и "идеологически верен", трудно отрицать удобство использования полноценной интегрированной среды разработки, которая скрывает от программиста всю "подноготную", позволяя не отвлекаться от непосредственно написания самой программы. Та же ситуация и со статическим анализом — приятнее, когда всё работает "из коробки", не отвлекая от непосредственного поиска ошибок в коде.

До версии 5.00 в дистрибутиве PVS-Studio поставлялся плагин-расширение только для одной интегрированной среды — Microsoft Visual Studio, а точнее говоря для её версий начиная с Visual Studio 2005. Но, начиная с 5-ой версии PVS-Studio, в дистрибутив был включён аналогичный плагин и для другой среды разработки — Embarcadero RAD Studio, для версий 2009, 2010, XE, XE2 и XE3. Вместе с этим в command line анализатор была добавлена и полноценная поддержка для препроцессора bcc (препроцессор C++Builder). Так что теперь все пользователи данной среды разработки также смогут полноценно использовать анализатор PVS-Studio, без необходимости "шаманить" со сборочной системой и самостоятельно парсить логи проверки (ну или устанавливать Visual Studio для работы с ними через плагин PVS-Studio).

Конечно, C++Builder (как часть RAD Studio, предназначенная для разработки под C++) не является самой популярной IDE среди C++ разработчиков под Windows. Можно предположить, что по популярности его опережают (помимо, безусловно, Visual Studio) и такие среды, как Eclipse и QtCreator. Почему же тогда мы выбрали именно этот IDE? Главной причиной, оказалась простота портирования существующего IDE плагина Visual Studio под этот IDE. К сожалению, PVS-Studio на данный момент не является кросс-платформенным проектом, как и её плагин под среду Visual Studio. А такие среды разработки, как Eclipse и QtCreator, наоборот, сами являются кроссплатформенными, и ориентированы на разработку кроссплатформенного ПО. Портирование же существующего IDE плагина PVS-Studio под такие IDE практически невозможно. Необходимо будет разрабатывать совершенно новый продукт. А это — также и дополнительные затраты на тестирование и поддержку, которые не стоит недооценивать даже для такого казалось бы простого приложения, как IDE плагин. Не стоит забывать и то, что данные инструменты широко популярны, прежде всего в open-source сообществе. Приобретение же такого закрытого и коммерческого продукта, как PVS-Studio, для пользователя open-source экосистемы будет скорее исключением. С++Builder же наиболее распространён, по понятным причинам, в корпоративном секторе, на который мы в данный момент и ориентируем наш продукт в первую очередь. Также, несмотря на своё нынешнее забвение, C++Builder был раньше (прежде всего вместе с родственным ему Delphi) популярен благодаря библиотеке VCL, и, как следствие, оставил за собой множество Legacy кода, который так-же необходимо поддерживать, а, следовательно, и проверять. Деятельность же Embarcadero в последние годы, как то дебют 64-битного режима в версии для XE3, ориентация на кросс-платформенность и активное продвижение нового framework'а FireMonkey как замены для устаревающего VCL, позволяют надеяться на ренессанс данной IDE.

Теперь остановимся поподробнее на непосредственной разработке расширения для RAD Studio, а точнее, на портировании Visual Studio плагина PVS-Studio под эту IDE. Наш IDE плагин разрабатывается с помощью C# для .NET/WinForms. Соответственно, он нативно поддерживается в среде Visual Studio. Сама Visual Studio, точнее, её ядро — это нативное приложение (правда, всё больше компонентов с каждой версией переписываются под WPF), взаимодействие её с managed плагином организовано не напрямую, а через COM интерфейсы. Эти интерфейсы формируют её так называемый extensibility API. Но, как это ни странно на первый взгляд, RAD Studio также способна подгружать managed библиотеки в качестве модулей расширения и предоставляет для них аналогичные COM интерфейсы. Скорее всего, это является тяжёлым наследием мертворождённого проекта C#Builder, который должен был обеспечить возможность разработки под .NET Framework из RAD Studio. Набор данных интерфейсов объединяется под термином OTA (Open Tools API). Работа с этими интерфейсами теоретически доступна из любого внешнего приложения. Тут стоит упомянуть, что RAD Studio предоставляет ещё один набор интерфейсов для создания именно нативных расширений (т.е. библиотек bpl) — NTA (Native Tools API). Причём некоторый функционал (как например, создание docking MDI рабочих окон) доступен только для клиентов данных интерфейсов. К сожалению, эти интерфейсы доступны только для нативных IDE модулей, написанных на тех же C++Builder/Delphi. Однако даже ограниченного OTA функционала оказалось для наших потребностей достаточно на 99%, а самым заметным из недостающего функционала стало как раз отсутствие способности к докингу у инструментальных MDI окон.

Несмотря на то, что обе IDE (Visual Studio и RAD Studio) предоставляют COM интерфейсы для managed модулей расширения, эти интерфейсы существенно между собой различаются. Логичным шагом для портирования IDE плагина под C++Builder является, выделение, использующего эти интерфейсы, кода в некоторую отдельную сущность, с собственным, уже единообразным интерфейсом. То есть можно говорить о создании "обёртки" для интерфейсов IDE. Это, в свою очередь, позволяет создать реализацию этой "обёртки" и для других сред разработки, в частности RAD Studio. Например, появляется внутренняя команда "открыть файл в редакторе IDE". Для каждой среды она будет реализована в соответствующей обёртке по своему, но весь остальной код плагина будет использовать единую сигнатуру для выполнения данного действия. Такой подход не был применён сразу, поскольку изначально плагин не подразумевал поддержку нескольких IDE, и обращения к API среды были размазаны по всему коду. Однако, путём незначительного рефакторинга нам удалось очистить код плагина от API-зависимых фрагментов, без изменения логики работы, обеспечив переиспользование кода для нового плагина на уровне порядка 80%. Более того, подобная реорганизация, помимо того, что мы получили идентичную функциональность плагина для RAD Studio, теоретически позволяет также использовать эти общие компоненты для создания плагинов и под любую сборочную платформу, поддерживающую подгрузку managed кода. На самом деле, упомянутый выше плагин для MSBuild также использует часть общего кода с нашими IDE плагинами.

В заключение стоит заметить, что модификация плагина описанная выше возможно позволит нам в будущем создать независимую полноценную UI версию нашего анализатора. По аналогии с некоторыми аналогичными opensource проектами, это станет шагом в сторону настоящей платформо-независимости PVS-Studio.